Re: package, package2, package3 naming-with-version exploit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux