package, package2, package3 naming-with-version exploit

Jan Zelený jzeleny at redhat.com
Fri Mar 29 12:28:07 UTC 2013


On 29. 3. 2013 at 05:33:59, Bohuslav Kabrda wrote:
> ----- 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.

Believe me when I say that I distinguish those two areas very strictly. But 
the point I was making is that the technical solution of multiversion 
packaging has a potential to bring such a mess in spec files that they become 
unmaintanable and therefore the solution would be practically useless.

I'm sorry to say that so far I haven't seen a single solution that would be 
acceptable for you while actually making packagers' lifes easier.

Thanks
Jan


More information about the devel mailing list