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

[Marvin Renich]

clone 885436 -1
reassign -1 apt 1.6~alpha5
retitle -1 /var/log/apt shows wrong architecture for arch:all packages
thanks

* David Kalnischkies <david at kalnischkies.de> [180102 06:03]:
> 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.

That seems wrong as well to me.

> 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.

Actually, it helps a great deal, even when a binary package changes
between native and all (either way), as long as the log gives the old
package's stated arch.  Whether changing architecture is rare or common,
the current log entry is unhelpful, and giving the old pkg arch is
significantly more helpful.

Determining both the new pkg arch and the native arch are trivial
without it being stated in the log; finding the old pkg arch is
non-trivial unless it is in the log.

> 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).

You are actually proving my point.  Knowing whether to look in
http://snapshot.debian.org/archive/debian/20171201/dists/buster/main/binary-all/
or
http://snapshot.debian.org/archive/debian/20171201/dists/buster/main/binary-amd64/
to begin with is a big jump forward.  By having the package
architecture, the URIs for both the Packages file and the .deb file are
deterministic.  If you only have the native architecture, you have to go
searching to figure out which package architecture is the right one.

The native architecture is a detail of the internal operation of
aptitude (and apt), and does not represent how packages are stored in
the archive or how packages are identified by users.

These log files are primarily meant for sysadmins, to record changes (or
intended changes) to the system, not as debugging aids for internal
apt/aptitude problems (though they are probably useful for that, as
well).

> 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.

I hadn't looked at apt's logs.  I also think this is a bug there, as
well.  I'm cloning this bug to apt.

...Marvin