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).