On 2013-03-28, Jan Zelený <jzeleny(a)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(a)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.
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.
-- Petr