Hi,
Quoting Neil Williams (2013-07-27 17:03:02)
> Check the config_str which is always output by multistrap and run just that
> command to apt. Add the APT::Default-Release=* option and see how that
> changes things.
When I do that, then there is no error (see below).
> There is no sane way for multistrap to know what the default release would
> be, so the wildcard is the only option without adding more complexity to the
> configuration.
Indeed but from your recent changes I see that you went the route of adding
more complexity.
>
> > $config_str .= " -o Dir::Etc=${dir}${etcdir} -o
> > APT::Default-Release=*" if (not defined $preffile);
>
> Try with the conditional removed (so that Default-Release is always set
> to * whether a preferences file is used or not. This may be the actual
> bug because I don't see a way in the apt *preferences* settings to
> change Default-Release which is actually an apt *configuration* change.
Yes, removing the conditional fixes the problem.
> Confusingly, apt has a completely separate setup for configuration changes
> versus preference changes.
There is something about this in the apt_preferences man page but it is
confusing as you say. As I understand it, the APT::Default-Release takes
precedence over everything specified in /etc/apt/preferences so I guess it is
safe to always set APT::Default-Release=* even when the aptpreferences
configuration option is set?
> Try the latest SVN with the aptdefaultrelease option in your [General]
> section and see how that works.
The changes work. With them I dont even need to set aptdefaultrelease anymore
because it will also default to "*" even if aptpreferences is given. But also
setting it to other values shows the expected behaviour. Thanks, this is fixed
then. :)
cheers, josch
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
