On Fri, 02 Aug 2013 01:06:41 +0000 adrelanos <adrelanos@riseup.net> wrote: > One of those existing packages, when upgraded in future, should fetch > a package from Debian testing using apt pinning. This is a sign of: 0: A bad package which needs to support a migration in the dependency 1: A broken fork which should repackage the old version if the migration cannot be supported 2: A broken implementation 3: A package which can correctly be described as toxic. > When a package gets upgraded by apt-get... There is no way I know of > for the package to: > > (1) add a new /etc/apt/sources.list, > (2) add new apt pinning settings to /etc/apt/preferences.d/ Correct. This should *not* be supported by any package. > (3) update package lists (apt-get update) and > (4) pull a new package from another repository (apt-get install > python-stem - only available in testing, not in stable) The correct solution is to backport the missing package to stable-backports. Even so, the package which needs the backport will need to itself be in backports - dependencies outside the current suite are not supported in 'main', that's why contrib exists. If you're working with a derivative, create a stable-backport suite and put *both* packages into it. Do *not* be tempted to force admins to use backports when upgrading by subverting the choice of apt sources - leave a working package in the current suite with a description of how to upgrade. apt sources are configuration files in /etc/, maintained solely by the local admin - packages have *no* rights to change, modify, remove or add apt sources except as installers or rootfs tools. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: PGP signature