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

[David Kalnischkies]

On Tue, Jan 02, 2018 at 01:11:32PM -0500, Marvin Renich wrote:
> * 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.

For apt I can decide and for apt I have to close this bugreport – you
can choose your preference between wontfix and notabug with the
reasoning following below + the usual backward compatibility reasoning
as we can't just break format.


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

Assuming the "old" version is the one you don't have information in
current Packages files for. Your tool installing the "old" version will
have this old one be the "new" one so an undo of the undo has your
problem. The "new" version being a now-disappeared version from
experimental/backports might be a slightly more realistic example of
this situation (especially for your tool I guess).


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

If we assume the old package started as pkg:all and became a pkg:native
you might be right. If the package started as pkg:native and ended in
pkg:all you haven't gained anything as by your deterministic reasoning
you are looking into the wrong file.

It is actually a good idea to look into the binary-all files for the
future, but at present they aren't used by apt¹ as arch:all packages
appear in the binary-any files – so they can easily not include the
arch:all version you expect to be there (as different archs can have
different versions of arch:all packages "installed" in the archive).


¹ apt supports using the binary-all file but based on the current
Release file metadata it figures out that it would be a pointless
download. The idea is to remove arch:all eventually from the arch:any
files but not all other tools working with Packages file handle it so
far.


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

Well, you can just as well come from the point of view that "all" is an
implementation detail a user shouldn't be concerned with. Realistically
a user isn't identifying a package as "native" or "all". Most are
probably not identifying a package with any sort of architecture, which
is why "apt install steam" works on amd64 even if (or in fact because)
it exists only for i386. The log file will speak of steam:i386.


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/fd2ae0f0/attachment.sig>