Hey folks, For a while now, the backports archive sets "ButAutomaticUpdates: yes" in its Release file, causing packages in the archive to be pinned with priority 100, rather than 1 (which was previously the case).
The effect of this is that once a backport package is installed and
a new version appears in the backport archive, APT will treat it as
an upgrade candidate. Cf. apt_preferences(5):
100 <= P < 500
causes a version to be installed unless there is a version
available belonging to some other distribution or the
installed version is more recent
While this might seem like a good idea at first — like when
a security fix reaches the backports archive — I think this actually
counters our stable policy, and backports are destined for stable
systems after all.
Our stable policy says that we don't upgrade packages with the
exception of pure security fixes or other fixes that are guaranteed
not to remove functionality or introduce big changes (and bugs).
Backports, however, may very well track a package in testing,
especially if the backporter has a vested interest in keeping up to
date with a package's releases even on a stable system, and
introduce major changes. Therefore, backports hold no guarantee that
they do not remove functionality or introduce gross new bugs.
In the past, you could always install a backport if you knew what
you wanted (apt-get install -t etch-backports …), but if you
actually wanted to get upgrades, you had to add a package pin
("release a=etch-backports"; priority:600). That is, the more you
wanted to deviate, the more explicit steps you'd have to take.
This behaviour has now been inverted: you can install a backport,
but if you do *not* want to receive upgrades automatically, you have
to install a pin. Put differently: to prevent automatic further
deviation from stable, you have to take additional steps.
I am sure we all agree that the
deny-all-but-what-is-explicitly-allowed policy is the better one. So
why did we make the switch?
Of course, once you install backports, you no longer have a stable
system, and hence our stable packages guarantee no longer holds.
However, many will agree that backports can augment a stable system
in useful and sometimes even necessary ways. A later version might
provide a required functionality, or a bug might only be fixed in
testing, forcing the admin to install a backport without really
wanting to give up the quality of the stable system.
The problem in the past was that security fixes to the package in
stable may well never reach users with backports installed. This
problem is actually not addressed, as security fixes might not
appear in testing anytime soon, nor is it guaranteed that the
backport will be upgraded.
However, unless the admin takes additional steps (= does not forget
to take additional steps), `apt-get upgrade` (no dist-upgrade
necessary) might suddenly introduce major changes.
I think we ought to revert this change and turn off
ButAutomaticUpgrades for the backports archive (and update
apt_preferences(5)).
In the long run, maybe we need a stable-backports-security
repository, which can be used to ensure that backport users don't
miss out on security fixes without having to accept major changes.
Ping me when the security team has 30 active members working 5 days
a week on Debian and I'll look into writing the dak patches. ;)
Thanks for your attention and comments!
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"without music, life would be a mistake."
- friedrich nietzsche
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
