package, package2, package3 naming-with-version exploit

[Jan Zelený]

On 29. 3. 2013 at 11:02:11, Tomas Mraz wrote:
> On Thu, 2013-03-28 at 14:43 -0400, James Antill wrote:
> > 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.
> 
> I can imagine only one reason for this desire - so that the user can do
> just "yum install foo" when he just wants the latest version of "foo".

In this case we proposed another solution which was turned down (I'm not sure 
exactly why):

Each package requiring multiversion support would have all these versions 
almost the same as they are right now. The only difference would be that there 
is a metapackage pointing at all time to the latest version.

Example:
python-3.2.3-7.fc17       (metapackage)
python2-2.7.3-7.2.fc17
python3-3.2.3-7.fc17

Metapackage "python" could be pointing to whatever version the maintainer 
thinks is the best, obviously the version of the metapackage would correspond 
with the version of package it points to. Update path is clearly defined and 
user can do both "yum install python" and "yum update python" without any 
confusion.

Thanks
Jan