package, package2, package3 naming-with-version exploit

[Jan Zelený]

Petr,
thank you very much for yout input, answers are below:

On 28. 3. 2013 at 13:31:07, Petr Pisar wrote:
> On 2013-03-28, Jan Zelený <jzeleny at redhat.com> wrote:
> > On 28. 3. 2013 at 13:53:15, Vít Ondruch wrote:
> >> My point is: "First step to find technical solution for some issue is
> >> admit that there is some issue".
> > 
> > Exactly my point. I want to find out if there is really a technical or
> > at least semi-technical issue or not. Saying "multiple versions of
> > a single package should be installable" is a "what", not a "why". We
> > need to figure out the "why" if we want to know if there is really an
> > issue that actually needs to be addressed.
> 
> 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.
> > 
> > > Would it be premature for us to release a backported .deb package of
> > > icecast 2.4-beta for Debian and Ubuntu, or would the additional
> > > feedback from our community be welcome?
> > > 
> > > We would of course make it very clear that this package would not
> > > yet be recommended for production use, and as such it would not go
> > > into our official repository until the code was declared stable by
> > > the Icecast team.
> > 
> > My preferred approach would be to explain how to merge the debian
> > packaging with a more recent tar-ball and rebuild a package out of
> > this.  I actually plan to include that on icecast.org, alongside
> > a similar description for Fedora/RHEL/Centos.
> > 
> > I do realize that this necessitates additional steps that might be
> > error prone. So a PPA approach might be easier for interested parties.
> > 
> > When it comes to the 2.4 beta I actually made the conscious decision
> > to version it so that no extensions to the version number itself are
> > necessary to ensure a clean upgrade path.  Beta1 is 2.3.99.0.

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.

> 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?

Thank you again for your input
Jan