package, package2, package3 naming-with-version exploit

[Jan Zelený]

On 29. 3. 2013 at 12:55:54, Petr Pisar wrote:
> On 2013-03-28, Jan Zelený <jzeleny at redhat.com> wrote:
> > On 28. 3. 2013 at 13:31:07, Petr Pisar wrote:
> >> E.g. this post has been sent to <icecast-dev at xiph.org> an hour ago:
> >> > Subject: Re: [Icecast-dev] Packages of icecast 2.4-beta?
> >> > 
> >> > > At Sourcefabric we are testing Opus streams from the Airtime
> >> > > broadcast automation system via Icecast 2.4-beta. Other developers
> >> > > in our community are testing video streaming with Theora. We would
> >> > > like to make it easier for our users to try this Icecast beta
> >> > > themselves.
> >> > 
> >> > That is sadly a typical problem with most distributions.  I wonder
> >> > what would be a good way to handle this gracefully.
> 
> [...]
> 
> > I actually see this as an argument for keeping things as they are. If
> > you have a package in beta, not ready for production use, you should
> > distinctly differentiate it from the production one you have on the
> > system.
> 
> Question was not how to distinguish. Question was how to serve both
> versions.
> 
> I you think this is imaginary problem, see Xorg. Now you have prerelease
> in F19 and F20. And yes, it has (a little bit) broken SDL.
> 
> >> Or we see for more than a month a broken dependency between
> >> perl-Math-Clipper (Perl binding) and clipper (C++ library) because
> >> clipper has changed API, there is no new perl-Math-Clipper yet and even
> >> if it was, it would break API with libraries and applications using
> >> perl-Math-Clipper.
> > 
> > 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?

Thanks
Jan