On Thu, Jun 26, 2014 at 10:58:38PM +0200, David Kalnischkies wrote:
> On Thu, Jun 26, 2014 at 10:30:24PM +0200, Johannes Schauer wrote:
> > Quoting David Kalnischkies (2014-06-26 21:48:42)
> > > I think it is a bad idea to use our lib-directory directly.
> >
> > if apt developers agree that it is a bad idea to allow 3rd party software
> > access /var/lib/apt/lists, then please close this bug report.
>
> Just to be clear: I think it is incorrect to use /var/lib/apt/lists
> directly as you can never be sure what is in there. If you get the
> filename from the API on the other hand, that is "okay".
So, in the light of acquiring additional files apt itself has no use
for, but other frontends want without implementing all the boring
security sensitive download of it, I had to think about this problem
a bit again.
As I don't want the frontends to control the storage location (that
would just mean having e.g. the big Contents files in three different
places just because frontends can't decide on a common location) I have
to store them in lists/ and expose information about them somehow
– especially also about the Release file they came from as I really
don't want them to parse these… (detached sig, clear sig, different
names, unsigned content in clearsig files, …).
The upside to this is that I can handle Packages, Sources and
Translation-* files in the very same way so they are exposed over the
same API and hence deal with your problem too, even through these files
hardly qualify as "additional".
So, long story short, the solution I would like to propose is:
$ apt-get files "Codename: sid" "Trusted: yes" "Created-By: Packages"
[…]
MetaKey: main/binary-amd64/Packages
ShortDesc: Packages
Description: http://http.debian.net/debian sid/main amd64 Packages
URI: http://http.debian.net/debian/dists/sid/main/binary-amd64/Packages
Filename: /var/lib/apt/lists/http.debian.net_debian_dists_sid_main_binary-amd64_Packages
Optional: no
Codename: sid
Label: Debian
Origin: Debian
Suite: unstable
Trusted: yes
Architecture: amd64
Base-URI: http://http.debian.net/debian/dists/sid/
Component: main
Created-By: Packages
Release: sid
Repo-URI: http://http.debian.net/debian/
Site: http://http.debian.net/debian
Target-Of: deb
[…]
So basically our trusted deb822 format we see everywhere else and most
people who will want to use it probably already have a parser for. Or
add a --format="$(FILENAME)" and you have just the filename(s) of
authenticated Packages files from a Release with the codename 'sid'.
(In both cases the filename given is already checked for existance and
if it is compressed you get the filename of the compressed file of
course)
The C++ interface is pretty much what it used to be with reading
sources.list via pkgSourceList, iterating over metaIndex's this creates
(~ Release files) to ask them which files will be (tried to be)
requested from here: IndexTarget, which is new in this context and
contains most of the data you asked for.
You can also now 'map' a metaIndex to a (new) ReleaseFile struct in the
Cache, which will actually contain codename and co – metaIndex has no
concept of codename, it just knows what was given in the sources.list,
while ReleaseFile actually contains the information parsed from an
{In,}Release file. (This used to be possible only for debPackagesIndex
as the information belonging to a Release file was stored as if it
belonged to the Packages file – which used to be correct for the old
flat-style repos) Both combined, you should have all the information you
ever wanted…
Sounds complicated, but should amount to only a few lines of code on
your end, just see the 'apt-get file' implementation for an example.
Some more detailed 'user' documentation can be found in
./doc/acquire-additional-files.txt [0].
I would consider this bug done if this code reaches a release (sofar it
is sitting in the debian/experimental branch in git as this is part of
the acquire system rework in general and one giant API break…), but
would be very happy if you and/or anyone else could comment on the
usefulness (or not) of it in the mean time. There are some things
still missing and I am not too sure if I will stick to the very generic
"files" command or invent something else, but that is at least the
general direction… Tech-preview status I would say.
Best regards
David Kalnischkies
[0] https://anonscm.debian.org/cgit/apt/apt.git/tree/doc/acquire-additional-files.txt?h=debian/experimental
Attachment:
signature.asc
Description: Digital signature