package, package2, package3 naming-with-version exploit

[Jan Zelený]

On 28. 3. 2013 at 17:45:27, Vít Ondruch wrote:
> Dne 28.3.2013 17:13, seth vidal napsal(a):
> > On Thu, 28 Mar 2013 16:36:27 +0100
> > 
> > Vít Ondruch <vondruch at redhat.com> wrote:
> >> <sarcasm>
> >> Ah, are we going to distribute this howtos instead of binary RPM's
> >> now? It is 4 easy steps, everybody can handle it. May be we could
> >> convert whole distribution into bunch of how-tos. It would be nice,
> >> because how-to cannot have broken dependency for example.
> >> </sarcasm>
> > 
> > The above is not necessary and not going to help the conversation.
> > 
> > Speaking only for myself the above just drowns out anything else you
> > might say which could be helpful.
> > 
> > Please refrain from comments like this in the future. You might find
> > them cathartic but they come at a cost of your input being considered.
> > 
> >> But please, Florian, seriously, I know all that. But still, that is
> >> not solution which fits everybody. People would need at least some
> >> level of understanding how things work. I want provide to all
> >> potential users all the software available, no matter what version of
> >> library it uses. It has to work using packagekit or yum. I can handle
> >> more work with packaging, but I must have appropriate tools for that.
> >> 
> >> Yes, there is my famous case with multiple versions of Ruby
> >> libraries, but there are other examples from other peoples in this
> >> thread and on other places. Please, let me to do my packaging right,
> >> i.e. use name and version as they are intended and don't abuse
> >> package for some deficiency in RPM and YUM.
> > 
> > You need to realize that this isn't a new problem nor is the ruby case
> > particularly novel.
> > 
> > 
> > I think the first time we encountered the problem on a non-kernel pkg
> > wanting co-installation w/yum was back in 2002 or 2003. I'm sure it was
> > even before that with up2date and rpm.
> > 
> > 
> > The trouble is this - the solution you and others have suggested
> > doesn't actually solve the problem it just moves it around. It also
> > makes the situation of dep resolution and global updates that much more
> > difficult. Which makes the management end of all this that much harder
> > on the folks maintaining systems with these tools.
> > 
> > I've not been working with the package-mgmt team in a while now but I
> > do not think that any of the team is ignoring the issues - they are
> > just far harder to balance packager needs, user needs and sysadmins
> > needs that it would otherwise appear.
> > 
> > 
> > -sv
> 
> Sorry to say that, but neither my sarcasm nor your comment brings
> anything new. If this problem was put first time on the table in 2002,
> then there already passed 10 years of excuses. It is interesting to see
> that our competition can do much more with our technology then we do.
> Well, I'm not going to comment any further on this particular branch of
> thread.

No, please do. I'm honestly very curious who came up with a solution of our 
problem [1] that is better than ours, using our technology. That might 
actually be the first constructive information in this thread.

And please don't think it's just 10+ years of excuses - we are not a bunch of 
guys who are just lazy to do this!

Thanks
Jan


[1] The problem of simultaneous installation and *maintenance* of multiple, 
totally incompatible, versions of a single package.