Page MenuHomePureOS Tracker

apt-file reports that the cache is empty
Open, LowPublic



apt-file reports that the cache is empty, even after sudo apt-file update:

E: The cache is empty. You need to run “apt update” first

/var/lib/apt/lists directory is populated.

Event Timeline

mladen created this task.Aug 2 2017, 04:47
chris.lamb claimed this task.Aug 2 2017, 05:11
chris.lamb added a subscriber: chris.lamb.
Wed 02 07:47 <         mladen > lamby: If you have time, please have a look at

is this still a relevant bug?

mak changed the task status from Open to Incomplete.Apr 10 2018, 18:38
mak changed the task status from Incomplete to Open.May 29 2018, 11:35
mak claimed this task.
mak triaged this task as Low priority.
mak added a subscriber: mak.

At the moment, apt-file is pretty useless on PureOS, due to the archive not generating a Contents file (or rather, an empty one).
I am not sure though whether it's worth fixing at the current point in time, because the dinstall runs are already really slow, extracting file contents will slow the process down even further.
So this will likely only get fixed when my patches to speed up the process and break it into smaller bits have landed.
Generating Contents is easily one of the most expensive tasks to do (I was under the impression that we were building valid Contents files though and even thought about disabling it - but apparently, it's slow already, even without building them (the archive never created Contents files))

One fun idea would be to import the file lists from appstream-generator, which produces them as a sideeffect. That would have almost no additional cost, and those contents data is generated cheaply. That however means that the Contents file would not know about symbolic links at all (asgen only looks at the deb packages' md5sums file, instead of doing a full extraction of the package contents - and the checksum list obviously does never contain symbolic links or special files)
it's an interesting idea though and maybe worth pursuing (asgen is really fast if you give it enough memory).
I'll add it to my todo list, it'll likely land together with a larger batch of quality-of-life improvements to the archive, and make take some time to develop.

Sorry for the inconvenience and for realizing the source of this issue so late!

<mak> if it's okay, I'll steal the bug report from you, because it's an archive issue - although the apt-file error message is also pretty bad

<mak> done - it's a low priority bug for me, compared to the other stuff, but I still hope to address it in some way soonish. Using the asgen data is very tempting, because it would give us highly up-to-date data for a low cost (as opposed to e.g. Ubuntu, where Launchpad is regenerating the Contents file weekly or daily, depending on the archive change frequency)

<mak>  as long as people rarely search for symlinks, it's a neat solution

This is an ancient bug. I think we should move it to "won't fix" or try and fix it.

mak added a comment.Jan 16 2019, 19:10

It's still on my todo list, but with a low priority, so it pretty much is at the bottom of the queue every time something else of higher importance is added.
Since we have AppStream and this feature isn't one of the most popular ones, its priority is low.
However, it is fixable and I intend to do so when the infrastructure redesign is applied.

Maneth added a subscriber: Maneth.Jun 26 2020, 11:26