package, package2, package3 naming-with-version exploit

[Bohuslav Kabrda]

----- Original Message -----
> 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.

Just a quick note:
Correct me if I'm wrong, but it seems to me that you (and some other people) don't distinguish between tooling for accommodating multiple versions of packages and actually supporting these packages.
To me, these are very different aspects - should RPM/YUM be able to support multiple parallel versions without the naming hacks? Yes. Should Fedora as a distro support numbers of multiple versions of packages? In my opinion, we should try to keep counts of supported packages minimal, as we do now. But that doesn't really depend on _how_ we package the stuff.
This is about providing the tooling to people who actually want to maintain these more versions in their private repositories or whatever.

-- 
Regards,
Bohuslav "Slavek" Kabrda.