On Wed, Jun 25, 2014 at 10:16:57PM +0200, Johannes Schauer wrote: > some software in Debian works on Packages and Sources files. Instead of > retrieving those from mirrors they could re-use the copies which are > likely present in /var/lib/apt/lists/. But there exists no way to ask > apt which mirror, suite or architecture any of these files belong to, > short of parsing the description string returned by > debPackagesIndex.Describe() I think it is a bad idea to use our lib-directory directly. A lot of strange stuff happens in there, from InRelease to Release renames as Julian mentioned, over gzip compressed indexes (Acquire::GzipIndexes) to files which are not authenticated. Sometimes even unused stuff is still there (List-Cleanup disabled – aptitude did it for a while if I remember correctly, if it isn't still doing it). I probably forgot the other more obscure half and nobody knows what the future will bring aka: This is a really horrible "interface" to work with so much that I would agrue that every user is a bug (but I guess this is mostly a "we have no other choice at the moment" bug…). I would treat it similar to the control files dpkg stores in its own lib directory: You know they are there, but you still should ask for the content via dpkg interfaces and not access/parse the files directly yourself as occasionally filenames/orga-structure changes and your tool/package would be one more thing standing in the way of progress. For binary packages Julian already mentioned the 'correct' API. I am pretty sure it could be improved though. Maybe EDSP(-like) could be a handy format for you as well as it bundles quite a few data files. Or just plain old 'apt-cache dumpavail'. Note btw that there are also flat-repositories (still) in existance which do not have suite, architecture and all that by design, so all you can really work with is the filename if you really want filename resolution instead of "all". For source, we have only a "find the (next) record for this package in all files" at the moment. We could change that -- one less program parsing our lib-directory might be a good motiviation to do that, if you tell us what you need exactly… It sounds a bit like you are trying to match sources.list entries to your configured sources to indentify which files you could reuse. If so I think you are trying too hard. Other tools like debootstrap and stuff do not do this either. If users really care about the wasted download, they will have a proxy configured anyway, non-root users might be suprised if days-old data from lists is used instead of fresh stuff acquired from the net, … If you like REALLY want to go the extra mile, you could write your own sources.list file, copy our lists directory to somewhere else and run apts acquire code against this lists directory and this sources. It will download the files missing, reuse uptodate files or update them otherwise and delete files via list-cleanup which are not referred to by your sources.list. This should be relatively sane and gives you all the features (like auto-proxy detection) you could possibly ask for for free as well. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature