[Aptitude-devel] Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error

[David Kalnischkies]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/aptitude-devel/attachments/20210929/0681cd4e/attachment.sig>