Re: Should fast-evolving packages be backports-only?
On 12/11/14 17:42, Scott Howard wrote:
> On Tue, Nov 11, 2014 at 2:35 PM, Rogério Brito <rogerbrito@uol.com.br> wrote:
>> On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
>>> However, candidate packages due to reason (c) above really are a problem,
>>> IMHO they shouldn't be in stable in the first place.
>>
>> Does this mean that I should ask for the removal of youtube-dl from testing?
>>
>> It will certainly bitrot in a stable release, as it supports downloading
>> from many sites, the target sites are moving too fast (that's the nature
>> of the web) and there's no chance that I will be hunting minimal patches
>> to fix breakage of multiple sites, as upstream generally refactors the
>> whole thing constantly and as multiple sites may get broken, the pile of
>> patches would sometimes be larger than the code to extract data from
>> some simpler sites.
>
> Maybe a decent release goal for Jessie+1: what to do with these
> packages that require changes that aren't fit for stable-updates to
> remain useful.
>
> CUT [1,2] I believe, was the most recent stab that this idea, but as
> Daniel Pocock pointed out there are an increasing number of
> cloud/web/networking/communications packages that require larger
> changes than stable-updates would reasonably accept. Such packages, if
> released in stable, would be unusable, or at worst dangerous, to
> users. As such, some are blocked from testing for now. The problem is
> that those packages can't be in backports because they can't be in
> testing because they can't be in stable because they can't be updated
> by stable-updates and need to be updated in backports which they can't
> be in because then they would have to be in testing. There's a
> chicken-and-egg game that prevents supporting those packages in
> Debian, users can't even say "I'll just run testing" since those
> packages aren't allowed in testing. I don't think backports being
> enabled by default, on its own, is the right answer (stable systems
> should be stable) - but some other mechanism might be appropriate for
> users to choose which packages they want continuously updatable.
> Rebecca's suggestion might be a clever way of obtaining such a
> feature: (1) blocking migration to testing, (2) maintaining in
> backports, and (3) incorporating some easy way for users to choose to
> pin the backports version or install from backports if not available
> via stable.
>
> [1] http://cut.debian.net/
> [2] http://lwn.net/Articles/406301/
>
Looking at it from the user perspective: users expect Debian packages to
be stable
So if we have some packages that will never be stable, as long as we
have a way to signal that to users when they choose the package, I think
we should make it as easy as possible to make them available in a stable
release.
backports already does some of that. Security team is using security
updates to do it with browsers. The only question is whether to have
packages that are always essentially like a backport.
Reply to: