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@xxxxxxxxxx> 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@xxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
