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

Re: Updates in the very-old-stable (was: Time to merge back ubuntu improvements!(

On Sun, 06 Jan 2013 02:44:42 +0800
Thomas Goirand <zigo@debian.org> wrote:

> On 01/06/2013 02:02 AM, Mike Gabriel wrote:
> > Hi Thomas,
> >
> >> I agree. It would be nice if it was at least possible to upload security
> >> updates
> >> right now to old-stable, even if that wasn't officially supported. At
> >> least, this
> >> would be a nice way to go forward (eg: based on "best effort", and
> >> without
> >> forcing added work on anyone (yet)).
> >
> > Puuhhh... openly allowed uploads without review process to a
> > not-any-more support version of Debian? This does not sound like
> > Debian at all, does it?
> That's not what I wrote.
> Also, I don't know why Neils wrote so much about
> forcing people when I wrote that we shouldn't.

No, you expressly indicated the prospect of this being forced:

> >> without
> >> forcing added work on anyone (yet)).

There can be no "yet". No implied force, ever.

> My
> intention was to write that I thought this could be
> an experiment for a start, without strong rules, to
> see what can be done. 

Then do it but start on a separate server, just like Emdebian did.

> Damned, am I expressing
> myself so badly? :(

> First of all, this could be a separated repo, it
> doesn't have to, and IMO shouldn't for such an
> experiment, overwrite what's in archive.debian.org.

archive.debian.org shouldn't be updated - what is old stays old, new
stuff arrives at the top of the stack. ftp.debian.org and
backports.debian.org are where updates are done.
> Last but not least, I don't understand why leaving
> unpatched packages on deprecated releases
> with absolutely no way at all to get them updated
> is a better thing than allowing maintainers to
> update their package if they feel like it.

That means that maintainers have to support deprecated upstream releases
- with all the bugs inherent in those releases. Most updates cannot be
backported to old releases because there are interdependencies on other
updated code.

It's not about prohibiting updates, it's that most maintainers don't
have time to support deprecated versions. Sooner or later, a maintainer
who does want to update an old version finds that the update is blocked
by another package which has be re-factored in the meantime, making it
impractical to backport the minor changes in package A as it relies on
massive changes in package B. This is the most common problem with the
current backports and that is within the current limits of support. The
longer the window of support, the more packages will have changed, the
more complex the backport becomes, the fewer packages actually get

This means that any backports which can be done are at risk of being
patchy, incomplete, untested, liable to generate new bugs and thereby
increase the workload of those maintainers long after the work of the
actual backport is complete. The longer the interval covered by the
backport, the worse the problem becomes.

This then means that security support for such versions is all but
impossible to achieve. Upstream don't want to know, the newest version
has diverged too far from the buggy version to identify the relevant

For this situation, the only sane security support is to upgrade to the
next relevant Debian release - the entire OS. At least that way, the
system migrates to a combination of software which has had an
appreciable amount of testing.

> If there's not enough manpower, we can just
> recognize that fact.

There's never enough manpower. This is about priorities. Most
maintainers prioritise the current stable release of whatever software
they use / package / maintain.

The further back in time this goes, the more likely it is that the
updates to one package will be utterly blocked by necessary changes in
another package somewhere down the dependency chain.


Neil Williams

Attachment: pgpYy2sqH37IO.pgp
Description: PGP signature

Reply to: