Re: apt_preferences
>>>>> "Daniel" == Daniel Burrows <dburrows@debian.org> writes:
Daniel> On Tue, Feb 26, 2002 at 11:15:01AM -0800, "Karl M. Hegbloom" <karlheg@microsharp.com> was heard to say:
>> I think that "aptitude" does not handle "/etc/apt/preferences"
>> (man apt_preferences) correctly, and I have a question about
>> what "apt-get dist-upgrade" is supposed to do.
Daniel> aptitude does not override the choices made by apt.
Daniel> Nothing special is done to support it either -- apt's core
Daniel> logic should handle all of this. It works for me: for
Daniel> instance, I have experimental in /etc/apt/sources.list,
Daniel> pinned at a non-default level, and aptitude does not
Daniel> attempt to upgrade dhcp-client to the experimental
Daniel> version.
Ok; I'll take your word for it. I had trouble seeing if it was doing
the right thing or not, since "testing" and "unstable" overlap so
much. It makes sense that the apt_preferences stuff happens at a
deeper level than "aptitude" itself. Of course that's the right
design, since to place that functionality in a higher layer would
mean duplication of effort for every application using the apt
libraries.
Daniel> There is one bit of ugliness, which shouldn't affect you:
Daniel> When you select a particular package version manually, the information
Daniel> about what you selected is not stored anywhere -- not in aptitude's
Daniel> persistent state information, not in apt_preferences.
Daniel> The reason is simple: there's nothing sensible to do. There's no way
Daniel> to know whether the user wanted to install just that version, or enable
Daniel> upgrades from the archive it's from; if that version is available from
Daniel> multiple archives,
Daniel> I didn't want to munge apt_preferences because that seemed bad and
Daniel> complicated; storing version information in aptitude's state directory
Daniel> would also be bad (since it would in fact override apt_preferences) -- in
Daniel> fact, the code to do this is there, but it's only used to communicate
Daniel> with a subprocess when using the transparent-su-to-root hack.
I wonder if you communicated about this with the Apt (deity) folks?
(rhetorical; don't answer me)
>> First of all, does "aptitude" support the "apt_preferences" mechanism
>> described in the "apt_preferences" man page? If not, it should! I'm
>> having a hard time telling if it has done the right thing or not --
>> there is no indicator as to what release each package is to be
>> downloaded from until it actually prints the URI while pulling them
>> in. IIRC, it pulled several or all of the updates from "unstable"
>> when it should have pulled them from "testing" (see below for
>> config).
Daniel> I'd have to work to not support apt_preferences. There's a wishlist
Daniel> bug about providing a column format for the release that a package is
Daniel> in; however, no-one has yet stepped forward to suggest a solution to the
Daniel> issue of "what do I do when there are multiple available releases?"
Have you thought of raising the issue on "debian-devel"?
Daniel> Probably I should put some of that in the detailed information screen,
Daniel> though.
That sounds good.
--
mailto: (Karl M. Hegbloom) karlheg@microsharp.com
Free the Software http://www.debian.org/social_contract
http://www.microsharp.com
phone://USA/WA/360-260-2066
Reply to: