package, package2, package3 naming-with-version exploit

[Petr Pisar]

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.

-- Petr