On Tue, Sep 28, 2021 at 06:38:05PM +0200, Axel Beckert wrote: > > I have no idea why this happens, but originally thought it might be related > > to > > not having run 'update' as a first step. > > I'd rather imagine something the other way round: > > I wonder if there is a kind of race condition if aptitude is running > and then either on the admin on the commandline or a background job > runs "apt update".
That can indeed mess up some things as the cache (which is then old) still points to file locations in the "old" files rather than what an update might have placed in there in the meantime. For a long-running process like aptitude it might actually make sense to grab the lists/lock to prevent an update process interfering – but that can technically happen to any libapt client, just that the window for e.g. apt-cache is far smaller. I don't know if that is really the root cause here through as such issues usually run into other errors (if not crashes in unsuspecting clients). Such a problem could be "easily" reproduced by starting aptitude & then modifying a Packages file in such a way that the stanza about the package you want to click on next in the interface is (re)moved. One of these days I have to try if we can make libapt hold onto the file descriptors while the cache is open, but that has all sorts of practical problems (like having hundreds of open file descriptors potentially exhausting limits, lifetime and stuff). > Thanks! There's an interesting fact visible. First let's look at that > package: > > ~ → apt-cache show texlive-fonts-recommended > Package: texlive-fonts-recommended > Version: 2021.20210921-1 > Architecture: all > > So this package in question is arch:all. > > But according to the screenshot, aptitude wants > texlive-fonts-recommended:amd64 for whatever reason — which indeed > does not exist. This is a misunderstanding. An arch:all deb file is always attributed to be of the native architecture, in your case amd64. That is because libapt makes a difference between a package(name with architecture) and a version (of a package with version number & architecture). Imagine a 'package' changing from arch:all to arch:any (or vice versa). Even through these versions have different architectures they will all be versions of the foo:amd64 package. Otherwise those transitions would require explicit user intervention (or a lot of code in package managers) as architectures would change, pins not apply anymore and all sorts of shenanigans. > I tried to fix this in zsh like this: > https://salsa.debian.org/debian/zsh/-/commit/801f5e105ad6d1f767d28c8311edd263790f419f 'all' is an invalid architecture, so while some parsers might accept it and do something roughly sensible, some others might explode and that is perfectly fine. Don't do this. Lintian might warn about this in the future. Note that the package might be 'all', but isn't M-A:foreign, so as above the package only satisfies dependencies on the native architecture. In the cross build this all package has the 'wrong' architecture, that is why it is purely virtual. Probably it was a mistake by the resolver to go down this path due to temporary unavailability of a better choice (aka the native architecture of an earlier M-A:foreign package). Currently not an avoidable mistake as the markup says its okay while it really isn't for crossbuilders… that is unrelated to this bug through (if by some miracle you are interested, look for "very foreign" aka "barbarian" architectures. libapt will allow experimenting with this concept soon, but at this stage (and hopefully forever) clients like apt and aptitude can be mostly ignorant about these topics). Best regards David Kalnischkies
signature.asc
Description: PGP signature
