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.
Wed 02 07:47 < mladen > lamby: If you have time, please have a look at https://tracker.pureos.net/T155
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
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.
Since we have AppStream and this feature isn't one of the most popular ones, its priority is low.
That hints that AppStream is a workaround. (And I'm guessing you mean https://appstream.pureos.net/amber-phone/main/index.html ). How can I use that system to find a given file, e.g. stdio.h ?
AppStream is more for app meta-data while apt-file basically searches a directory of ASCII text to find specific files inside packages. I'm not sure if you could use AppStream as an apt-file replacement.
stdio.h is a C Standard Library Header file, it should be on your system already. If not, you might look in libc6-dev for example.
What I'm wondering is: why isn't the necessary data automatically generated at package build time and included as a file (perhaps named PACKAGE.contents) in the .deb file? Then to build the Contents file for a repo would just involve scanning through all the .deb files and extracting the .contents file from each and then concatenating them. I don't understand the Debian package build system well enough to know why it doesn't work this way.
I just started using PureOS and the failure of apt-file to work hit me from day one. I wasted probably a day (5 hours? 9 hours?) figuring out that this was due to the empty Contents files. I didn't notice that the Contents files were empty and wasted much time checking other things before I finally tried downloading them by hand and uncompressing them to see what was inside (nothing!). The error message that apt-file gives in this case is vastly unhelpful. It was completely mysterious also why “apt-get update” wasn't creating local copies of the Contents files (presumably it realized they were empty and then ignored them without any warning message).
would be very neat if apt-file would be usable:
I often only know the name of the binary I want to execute, but not necessarily the binary package that contains it