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


Reference: https://forums.puri.sm/t/unable-to-update-the-apt-package-cache/1162

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.

mladen created this task.Aug 2 2017, 11:47 AM
chris.lamb added a subscriber: chris.lamb.
Wed 02 07:47 <         mladen > lamby: If you have time, please have a look at https://tracker.pureos.net/T155

is this still a relevant bug?

mak changed the task status from "Open" to "Incomplete".Apr 11 2018, 1:38 AM
mak claimed this task.May 29 2018, 6:35 PM
mak changed the task status from "Incomplete" to "Open".
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 17 2019, 3:10 AM

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.

Add Comment