Bug#752702: apt: please add a way to to retrieve the location of Packages/Sources files in /var/lib/apt/lists/
Hi,
Quoting David Kalnischkies (2014-07-08 19:24:33)
> Well, I still kinda like my "workaround" presented in my first mail as
> it tries to solve this usecase at a higher level, which you haven't
> commented on so far.
Sorry, let me do that now:
> 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.
What do you mean by the "apts acquire code"?
Otherwise it sounds like a good idea but it still leaves me with somehow having
to interpret which file in my new lists directory represents what. And there
I'm still at the mercy of apt not changing the filename pattern (which is a bad
idea). So I would still need a way to know which file represents which of my
results. After all, for bootstrapping for example one needs at least two files,
one for Packages and one for Sources and more often than not it's even more
files because one needs more than one architecture.
> Regardless if you want to use the files apt already has or not, you
> still have to get those files if you can't find them (e.g. stable
> machine trying to make an anaylse for unstable). So you need acquire
> code to do all that and all these tools probably don't want to
> reimplement what apt already does in all its glory with multiple
> methods, proxy detection, security and what not (or, they at least
> should not).
You are right. It would be great if I could let the apt code do all that for me
instead of hacking something together as I have done it until now.
> On the other hand, you could let apt do all this for you by creating
> a few directories, a sources.list and set some config options. You get
> file reuse for free then if you copy the lists directory over…
I know how easy it is to let apt work with a completely different set of
directories (I implemented my own minimal multistrap-like tool) but same
argument as above: I still need to know which of the downloaded files in my
lists directory is which.
> This way a 'dumpavail' would include only packages you care about (as
> the sources.list comes from you), up-to-date files already downloaded
> are reused (instead of potentially reusing months old files if user has
> no way of updating as she isn't root) and you get told if one of the
> files is not as trustworthy as you might want (as apt-get update or
> similar carries a warning/error instead of you guessing based on other
> files (not) present in lists).
But `apt-cache dumpavail` does only give me binary packages and not source
packages. Is there a way to get source packages too?
> [We would need a 'dumpavailsource' (or similar such) of course]
Oh right, yes :)
> (This thinking is shell-based as I am most familiar with it thanks to
> our tests, but I assume it is even better/simpler with python-apt)
I guess your method would work if there was a dumpavailsrc. Then one would use
apt to download or update all the archives one wants and use two calls to get
all binary and source packages.
How hard is it to create a dumpavailsrc?
cheers, josch
Reply to: