package, package2, package3 naming-with-version exploit
juanmabc
juanmabcmail at gmail.com
Fri Mar 29 00:55:20 UTC 2013
On Thursday 28 March 2013 14:43:06 James Antill wrote:
> I agree this is a problem, everyone who knows how Fedora packaging
> works has said, to you, some variant of:
> The technical problem is being able to install multiple versions of a
> package, and you can do that now (and have been able to for the last 10
> years).
> Here is a long list of technical reasons why your desire to have all
> the parallel installable versions of "foo" called "foo" is not going to
> work.
> This is because you don't understand the problem, or are ignoring it.
> Using the package name to differentiate N different packages is by far
> the easiest thing for packagers and all of our packaging tools. It is
> also almost always the best thing for the user as well, and in the cases
> it isn't so great can be worked around.
> No, the reason to "dismiss" the idea is because it is worse than the
> alternative that works now.
> Maybe if you think of the problem differently it will help you
> understand.
> Imagine that we have N packages that provide a "bourne shell" and they
> are called bash, dash, ksh and pdsh ... they all want to be allowed to
> be installed "in parallel" and updated at different times etc. and
> currently we can do this, we just give them different package names.
> However they are "obviously" just name mangled versions of "sh" and it
> looks ugly for the user not to be able to do "yum install sh" or
> "yum upgrade sh" and it do "something"[1]. So the feature is requested
> that we rename all four of them to "sh" and "just" have some new rpm tag
> saying "this is the bash variant" etc.
> koji/bodhi/yum/rpm/etc. will all have to be updated to understand this
> new rpm tag, which will be a huge amount of work, but at least the user
> will be able to run "yum install sh" at the end.
> So we now have bash, dash, ksh and pdsh all in a single specfile ...
> hopefully a single package maintainer owns all three versions, because
> if not then every change for each stream will have to be co-ordinated
> with every other maintainer. All the maintainers will also now have to
> download all the data for each variant (git clone sh will now require
> all the data), and they'll either need to test all variants whenever
> they make a change or hope they didn't break anything in any of the
> other variants.
> But, it turns out, those variants are not _identical_ (or we could just
> have one of them, surely) so the other packagers whose packages require
> or conflict with only "the pdsh variant of sh" will have to use some
> much more obscure method to specify exactly which versions of "sh" they
> require/conflict with (or users will be very unhappy that it should work
> with the "ksh variant" installed, but the packaging doesn't allow it).
> Also, it turns out, some users may actually want have installed "the
> ksh variant" and not "the pdsh" variant[2] ... so now all of our UI
> needs some way for the user to easily differentiate between the
> different versions of "sh" (means we'll need to output that new rpm tag
> in all the places we currently output nevra, and likely all the places
> we output name).
> Then we'll need to change the input UI side so that the user can
> specify that tag everywhere (Eg. yum list <only show me the zsh
> variants>).
> Then we'll also have the problem of users talking to
> developers/maintainers and saying things like "I have a bug in sh" or "I
> install sh and XYZ doesn't seem to work", so we need to somehow fix all
> the users to not just say "sh" all the time anyway.
> That seems like a _lot_ of work, and a much more complicated solution
> than just having all 4 packages "Provide: sh" (or even have the user use
> "yum install /bin/sh") ... and ultimately provides no actual benefit.
> [1] Some random version of sh, all uninstalled versions or a random
> uninstalled version or something else are all viable definitions of
> "something" here.
> [2] For example crazy users not wanting to put things in rpms, and just
> managing the deps. by hand (those variant tag things are really
> confusing).
My initial concern, multiversion, would have nothing to do with aliases, and
just thinking on solving/implementing it would require another thread. The
fact that sh would reflect bash, csh, pdsh, etc. is completely another point.
By the way, i think i've seen yum install vnc-server (generic) install
tigervnc-server (specific or fedora default).
pkg-1.0.x.rpm
pkg-2.0.x.rpm
Again: pkg2-2.0.0.rpm, no sense.
But you maybe are right in some point, UNIX is not really multiversion
welcome, for starters, you can not have two mplayer binaries in an usual way
(/usr/bin), that's obvious, and that's cause the path for binaries itself, you
would need /usr/bin/mplayer-1 and /usr/bin/mplayer-2 and maybe some default/
alternatives for /usr/bin/mplayer. so the version becomes part of the command
itself (mplayer-1 or mplayer-2) but that's at binary file level and cause
filesystem hierarchy works that way (and I'm not saying it should keep working
that way, but that's a filesystem issue not a packaging issue).
More information about the devel
mailing list