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? :( Yes. > 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 backported. 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 fix. 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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpc1aB8872Ea.pgp
Description: PGP signature