martin f krafft schrieb am Thursday, den 24. January 2013:
> 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.
This mail would have been a target for the backports users mailinglist.
However backports is not stable and it was never intended to be stable.
> 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.
And several users failed to upgrade the backports which is imho more harm.
> 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.
Now are some years...
> 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?
Nope, I don't agree.
> 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.
It helps to read the policy, a security upgrade does not need to reach
testing.
> 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)).
I don't think so.
>
> 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. ;)
If you want to maintain such a repo, go ahead. I don't think we have the
manpower to maintain another security branch.
Alex
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130125064922.ga3...@hawking.credativ.lan
