* David Kalnischkies <da...@kalnischkies.de> [180101 15:48]: > On Thu, Dec 28, 2017 at 12:45:14AM +0100, Manuel A. Fernandez Montecelo wrote: > > > In the extremely rare (I think) case where an upgrade (or downgrade) > > > replaces a specific architecture package with an architecture all > > > package, or vice versa, I would be okay with my script breaking because > > > it does not have enough information from /var/log/aptitude to get it > > > right. E.g. I think it is okay to arbitrarily choose one architecture > > > or the other, but I think it is more useful to know the architecture of > > > the package being replaced than that of the one being installed. > > > > I wonder if it's because apt treats internally :all packages as the > > native arch, but it doesn't make much sense, I think that the string > > printed should still be :all. > > The architecture for a package in apt is never 'all' as this isn't > a property of the package for preciously the reason Marvin outlines as > "extremely rare" case – it just isn't that rare.
[good explanation snipped] Thanks for the explanation. However, I believe that the log file should still identify the architecture as specified in the control file, rather than the architecture that apt is using for dependency and upgrade resolution. The log file is used by the human (or a script) after the fact to identify what happened; it is irrelevant in that context that aptitude internally substitutes the default dpkg architecture for arch:all packages in aptitude's internal processing. Even if you think it is not irrelevant, it is much easier for a human or script to take pkg-name:all from the log and deduce that aptitude used pkg-name:amd64 in its processing than it is for a human or script to see pkg-name:amd64 in the log and then try to determine if it is really pkg-name:amd64 or was originally pkg-name:all. 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. ...Marvin