Re: Should fast-evolving packages be backports-only?
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/
Reply to: