On Mon, Jan 01, 2018 at 05:09:21PM -0500, Marvin Renich wrote: > IOW, using pkg-name:amd64 in the log loses information that is harder to > recover, while using pkg-name:all hides an internal detail of aptitude's > processing that is trivial to obtain.
I can't argue about aptitudes log, but it sounds like it would be similar to /var/log/apt/history.log in what it contains. In that log it is also always pkg:native instead of pkg:all. I don't think "sometimes" saying pkg:all will help you much as there are still the "rare" situations in which that info will be wrong as the 'all' applies to the old/new version only, so you have to work with this either way and it is "just" a matter of how often a certain codepath is called. Perhaps it is a matter of what you are doing that you need this architecture – I can only imagine it being needed to guess download URIs which I consider a problem enough (mirror selection, filenames, security, …) that native/all is trivial to solve (e.g. try all after native failed) or is solved as by-product (for security you need indexes and in those indexes the filenames are given). Note that a Pre-Install-Pkgs hook (used e.g. by apt-listchanges) has this information available as it gets told "all" (for some value of all) information about the (up to) two versions involved in the action, so you could also write your own log file… But as said, I am not here to decide what aptitude should (not) do. I am just saying what apt does (not) and why in a similar case. Best regards David Kalnischkies
signature.asc
Description: PGP signature
_______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
