Re: Can a package pull a another package from another repository to be added?
On Fri, Aug 2, 2013 at 3:06 AM, adrelanos <adrelanos@riseup.net> wrote:
> 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/
While this might technically looks easy on first glance, you really
shouldn't do this. Its an (unwritten) rule that a package is not
allowed to mess with APT configuration and packages who do it
are usually frowned up to (look out e.g. for Chrome).
The problem with sources.list is that you don't know how the user
is setup. The user might has testing in the sources, but as a CD-ROM,
a local mirror, a non-public mirror, … you have no idea which mirror
should be used as the mirror used for stable might be a partial one,
so you can't just rewrite this line. You also have no idea if the user
has an internet connection at all (various offline methods exist) or if
and how to configure firewalls/proxies between user and internet.
The config files might be (partial) under control of management systems
like puppet or chef, so it ends up being exported to other systems or
is overridden …
(that is not a complete list, just a few I recall seeing in bugreports)
With preferences it gets even more problematic as the user can have done
anything, so that your added rule is either overruled by user settings
or your rule overrides user settings, both usually with the wrong effect.
Especially as you can't just choose a pin-value without knowing the
current setup and the intend behind it …
So in short: You are asking for A LOT of trouble.
> (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)
These are the minor hazels then. There are workarounds for this,
but I am not going to tell you as its getting only worse…
> If the package would depend on the package only in stable in the first
> place, it wouldn't install at all, since apt pinning isn't set up yet.
> Its a deadlock.
>
> Do you have any idea how to pass the deadlock?
The solution usually taken can be described with one word: backport.
Take the package from testing, build it for stable and upload it to
your distribution archive. It gives you also the added benefit of not
upgrading (or deadlocking) system if this testing package starts to
depend e.g. on a newer than stable libc6.
(add a ~something to the version number so that with jessie release
users are upgraded to the Debian package)
The downsize is of course that you have to repeat this step for any
not-in-stable dependency as well as for every new upload, but that is
minor work compared to all the support you have to provide for the
systems your 1000+ lines of sources/preferences writer has destroyed
as you haven't considered each and every possible setup in the wild.
(And don't forget all the hate you will get from me and other deity@l.d.o
inhabitants because your users end up reporting bugs about APT)
Best regards
David Kalnischkies, waving with his APT hat
Reply to: