package, package2, package3 naming-with-version exploit

[James Antill]

On Thu, 2013-03-28 at 13:53 +0100, Vít Ondruch wrote:
> Dne 28.3.2013 13:30, Jan Zelený napsal(a):
> > On 28. 3. 2013 at 12:59:44, Vít Ondruch wrote:
> >> Dne 28.3.2013 12:09, Florian Festi napsal(a):
> >>> This is done to make life easier for package maintainers.
> >> Sorry, you definitely not speak for me! This are just excuses. And I
> >> asked already several times to have some way to reliable support
> >> multiple version of packages without mangling their names.
> > Víťo,
> > I certainly understand your frustration, as it comes from talking about this
> > topic over and over again. However Ruby community is a *very* special case in
> > this regard and I'd like to treat it as such.
> >
> > If you want, we can start a discussion here. But if we do, let's keep the
> > discussion strictly constructive and just about *technical* problems. Let's
> > not take this to design level of things, as Ruby and Fedora are two completely
> > different worlds that will never be fully compatible by design. Therefore the
> > final solution (if there is any) has to be some sort of compromise.
> >
> > Thanks
> > Jan
> 
> My point is: "First step to find technical solution for some issue is 
> admit that there is some issue".

 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.

...you then ignore the second part of what they told you (not admitting
any of those problems, nor providing viable solutions).

> It was clearly admitted by "juanmabc" that there is issue, he also made 
> proposal how to solve it, but it was immediately dismissed with remark 
> of "easier life for package maintainers",

 I think you need to read Florian's reply again.
 Also, while I understand you do not speak English natively, please do
not use words like "immediately dismissed" when Florian obviously spent
a lot of time trying to educate everybody (for something that has been
explained repeatedly in public, and has multiple wiki pages).

>  which was inappropriate 
> generalization from my POV.

 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.

> I understand that everybody of us has a lot of thinks to do. That is not 
> reason for dismiss such idea.

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