package, package2, package3 naming-with-version exploit

[seth vidal]

On Fri, 29 Mar 2013 14:40:35 +0100
Jan Zelený <jzeleny at redhat.com> wrote:

> > > This is very valid concern. However I'm not sure it's something
> > > that can be solved just by the multiversion support in rpm/yum,
> > > there are more pieces here to be put together.
> > > 
> > > My first impression of this is that someone screwed up - either
> > > upstrem by breaking API or maintainer by pushing the update
> > > without consulting stakeholders beforehand. Again I don't beleive
> > > multiversion support can solely solve this problem, can it?
> > 
> > In my opinion multiversion is solution. From practial as well as
> > theoretical point of view. You cannot dismiss reality just by
> > blaming insufficient communication. Have you seen GTK or Python?
> > 
> > I do not expect everybody will utilize multiversion once it will be
> > available. But it's really pain to live without it when it's needed.
> 
> But we don't live without it, we do have multiple versions of single
> packages in Fedora, they are just not super-pretty. See my proposal
> of metapackages. Do you think it would improve the situation? And if
> you think it wouldn't, could you specify why?
> 

We've been doing multiple versions for longer than that. Ultimately the
kernel is multiple versions and it has no weirdness with the name. The
trick is that the files owned by the kernel pkgs never overlap one
another.

If the packagers want to build pkgs which never touch one another then
you can expand the installonlypkgs option in yum to include other types
of pkgs and handle it. but the packaging rigor is quite extreme. 

/usr/lib/somepkg/2.1/
/usr/lib/somepkg/3.1/

and there must be no other files outside of there or if there are they
cannot overlap each other unless the files are ALWAYS IDENTICAL.

But if you do that you have to be very specific and very careful with
obsoletes.

-sv