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

[David Kalnischkies]

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.

You had basically the same problem before MultiArch: packages had no
concept of architecture in this dark age, so "ieee-data" was either
$native or all (or some architecture you had forced on your system).


Back to this "rare" case: Be careful what you wish for. If you think
this through you need two packages for this: flip-pkg:all and
flip-pkg:amd64. They need to have the same name display to the user,
they need special handling in the resolver to consider them an upgrade,
they need special handling in the UI to hide the remove of :amd64 and
the install of the new :all (or vice versa) and show an upgrade. If you
have modes disabling removals/new install or fail if they appear in the
solution be sure to add special cases, too.

That would of course been in conflict with the goal of requiring
a minimum of changes for multiarch in libapt users – that goal wasn't
there from the get go: The paragraph isn't theory, its actually a war
story of my first attempt which worked. Mostly. It was just… ugly and
the ecosystem would surely be different by now.


The problem is perhaps that what apt considers a package is not what
a user commonly understands to be a package: For a user a package has
a name, an architecture, a version, dependencies, a description, ….  For
apt a package is just a name. It might not even be a real package, it
could just as well be a virtual one. That name appears in dependency
lines and to keep our resolution consistent in a multiarch-world the
architecture of the dependency became part of the name (in a slightly
convoluted way to keep backward compat).

Long story short: What a user calls package is what apt calls version
– and indeed: asking a version for architecture will give you 'all'.
If that is what you want to switch to on the other hand… I would stick
to the current scheme simply because it is consistent with the past (aka
no flagday) and there are no "rare" edgecases: Its pretty clear that you
have to deal with 'all' one way or the other and you have to do it
either way anyhow (its probably not too bad. In all likelyhood you
"need" the architecture to guess filenames for download. There are so
many problems with it starting with security and different archive
layouts that 'all' is a small problem in comparison in my opinion).

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