gpg: failed to create temporary file '/var/lib/lurker/.#lk0x5755f100.hantslug.org.uk.3746': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Wed Oct 7 13:05:55 2009 BST
gpg: using DSA key 20ACB3BE515C238D
gpg: Can't check signature: No public key
On Wed, Oct 07, 2009 at 11:46:20AM +0100, Vic wrote:
>
> > It follows on from the package update policy for Debian stable,
> > which is that bug-fixes for packages are always back-ported to the
> > original pacakge version. Thus, over the lifetime of a stable release,
> > the "upstream" part of the package version will never change (although
> > the debian patch version will). This implies that no security upgrade
> > will ever attempt to install new packages. The safe-upgrade option
> > matches this policy, and won't ever try to install new packages
> > automatically as a result of the upgrade.
>
> So what would happen in the event that a security upgrade *did* require
> new packages[1]?
>
> I recognise that this would be a deviation from the Policy - but people
> are human; mistakes happen.
This is why Debian policy is enforced by automated processes -- as
an example from the development process, a package won't be permitted
to migrate from unstable to testing if it has outstanding RC bugs
against it. I haven't checked, but I would expect them to have an
automated checker script that verifies that the dependencies of a
package uploaded to the security-updates repo are the same as the
dependencies of the package it replaces in stable. To bypass this
check, the system would need an override from one of the ftp-masters:
a decision subject to additional human oversight.
> Would safe-upgrade refuse to install the security upgrade, or would it
> pull in the new dependency?
It would fail to install the security update, and tell the user
that the main package had been held back. The user can then either run
aptitude dist-upgrade, which will attempt to install all such pending
updates, or simply aptitude install <package>, which will upgrade the
single package, pulling in the additional libraries it requires.
> It strikes me - and I could easily have misunderstood the distinction here
> - that the latter case here would make the option entirely irrelevant, but
> the former, whilst guarding against deviations of Policy by the repo
> maintainers, leaves known, patched problems in place.
>
> Have I got that right?
Yes. Bear in mind, though, that in order for the situation to occur
on a system installed with stable, there would have to be at least one
layer of automated process within Debian's systems to get around, and
the policy violation would have to be OK'd by (at least) a second
human (not the uploader).
> [1] The argument "that would never happen" requires that every repo
> maintainer never makes a mistake, ever. Aside from that being an
> unlikely situation, it also begs the question: why do we need an
> option to protect against such occurrences if they are entirey
> impossible?
They're not impossible -- extremely unlikely to happen
accidentally, but not impossible. And, as Alan pointed out, it gives
the admin options for managing their packages.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- "How deep will this sub go?" "Oh, she'll go all the way to ---
the bottom if we don't stop her."
