[Aptitude-devel] Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[David Kalnischkies]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20180102/4f4ccb4b/attachment.sig>