Debian Bug report logs - #848194
Want way to get Release (or InRelease) file from cache

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Ian Jackson <[email protected]>

To: [email protected]

Subject: Want way to get Release (or InRelease) file from cache

Date: Thu, 15 Dec 2016 01:35:14 +0000

Package: apt
Version: 1.3.1
Control: block 848193 by -1

Dear apt maintainers:

I would like a way to get the [In]Release file corresponding to the
source from which apt got (or, I guess, would install) a particular
package.

I can use `apt-cache madison' to find the archive URL and the
locations within that archive.  The [In]Release file has a predictable
filename (derived from the URL) in the apt cache.

May I fish the [In]]Release file out of the apt cache ?

Things I want to avoid include:

 * Breaking if apt changes the cache layout.  How likely is this ?
   Relying on the cache url->filename mangling seems a bit rude.

 * Consuming a file whose signature has not been verified by apt.
   That would be a vulnerability.

 * Becoming confused if there are both Release and InRelease files.
   I guess I can just use InRelease if I find both ?

 * Implementing my own signature verification, resulting in the
   possibility that my set of approved public keys or my verification
   criteria might differ from apt's.

Do you have advice for me ?  If there is not currently a good way of
getting this information (which there may not be) then please take
this wishlist bug as a request for a way to get it.  Also, in that
case, please let me know whether it would be bad of me to implement my
approach as described above, in the meantime.

Thanks for any help you can provide.

Regards,
Ian.

-- 
Ian Jackson <[email protected]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #12 received at [email protected] (full text, mbox, reply):

From: Ian Jackson <[email protected]>

To: [email protected]

Subject: Re: Want way to get Release (or InRelease) file from cache

Date: Thu, 15 Dec 2016 01:39:27 +0000

Control: severity -1 wishlist

(Sorry, forgot that.)

Ian.

Message #19 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: [email protected]

Cc: Ian Jackson <[email protected]>

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Sun, 18 Dec 2016 14:14:17 +0100

[Message part 1 (text/plain, inline)]

On Thu, Dec 15, 2016 at 01:35:14AM +0000, Ian Jackson wrote:
> I would like a way to get the [In]Release file corresponding to the
> source from which apt got (or, I guess, would install) a particular
> package.

Got vs. would is a HUGE difference – and the information of 'got' is not
stored anywhere so what you want to know is not possible, especially if
the system isn't fully upgraded yet and you have to consider pinning
(ignoring that users could be changing it at runtime).  You can
approximate all this with guesswork, but the amount of times you will
guess wrong will make this whole endevour borderline useless as a user
will never be able to reasonably predict what the result of a command
issued will be (in my opinion at least).


> I can use `apt-cache madison' to find the archive URL and the
> locations within that archive.  The [In]Release file has a predictable
> filename (derived from the URL) in the apt cache.
> 
> May I fish the [In]]Release file out of the apt cache ?

No. The filenames are not stable. We need less things fiddling with our
files directly, not more, as that stops us from doing changes easily
(changing sources.list format, keeping files compressed, …).

Also, have you considered that some repositories are flat, some users
have CD-ROM (DVD, USB, …) sources and stuff. You really don't want to
get into that kind of business…. Especially the flat repos have no
concept of "suite" so you are out in the dark there.


> Do you have advice for me ?  If there is not currently a good way of

My advice is don't.

'apt source' defaults to the newest version if no default release is
configured simply because people tend to want the latest source. The
"few" which don't tend to be the people the suite is the hardest to
find: stretch, stretch/updates, stretch-backports are all perfectly
valid choices…

If you want people to be able to easy get the version they have
installed you need a version based interface, trying to do it via
suite/codenames will not end well [disclaimer: I know nothing about
dgit].


> getting this information (which there may not be) then please take
> this wishlist bug as a request for a way to get it.  Also, in that

Johannes Schauer had asked about the inclusion of Release files in
'apt-get indextargets' a while ago. It's a slight stretch, but its the
only place where this would make sense & relatively easy to add.


> case, please let me know whether it would be bad of me to implement my
> approach as described above, in the meantime.

Yes it would as already explained – beside you are the first person in
years I hear using 'apt-cache madison'…

Given that I haven't understood why you want to access the Release file
at all I can't offer specific advice, but a solution is likely to
involve 'apt-get indextargets' in some way. Something like getting all
Sources files, grepping for the version in them and for the Sources file(s)
which include the version you where looking for use the attached
release information like suite and co [I am assuming you want to get to
that as not that many people are interested in hashsums…].

| apt-get indextargets "Created-By: Sources" --format='$(FILENAME) $(CODENAME) $(SUITE)' | while read file codename suite; do
|   if /usr/lib/apt/apt-helper cat-file "$file" | grep-dctrl -q -PX apt -a -F Version -X '1.4~beta2'; then
|     echo "FOUND in: $codename ($suite) $file";
|   fi
| done


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

Message #24 received at [email protected] (full text, mbox, reply):

From: Ian Jackson <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: [email protected]

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Mon, 19 Dec 2016 01:18:13 +0000

Hi.  Firstly, thanks for your attention.  I appreciate you helping me
make my code do the right thing, and not store up problems for the
future.

I get a sense of puzzlement from your mail.  I will try to explain why
I want these seemingly-daft things.

Right now, a dgit user can easily get the source code for the version
of the package in sid.  That's the default, in fact.

However, a user who wants to change the behaviour of their own
computer, which may well be running stable or even oldstable, probably
does not want to take on a backporting task too.  They want the source
code for the version they're running.  (Which as you allude to might
be from -security or -backports.)

Right now, users have to dig a bit to find the right information.
Take a you look here at the advice under `Finding the Debian release':
   https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user&apropos=0&sektion=0&manpath=Debian+testing+stretch&format=html&locale=en

I would like to make a way to a user to ask dgit for "what I'm
running" (this request is #848193).

You mention version numbers.  Obviously the user wants the right
version.  But the version number is not sufficient.  dgit provides a
fast-forwarding git branch for each suite.  To get the right history
structure it is necessary to know not just the sequence of version
numbers, but also any shared git history (from the dgit git server).

I think all the information I need is in the Release file (assuming we
can somehow identify what the right Release file is).  That contains
both the suite name and the codename, and also the Origin field tells
us the distro.  (dgit needs configuration for each distro anyway, so
just the distro name is enough.)

David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or InRelease) file from cache"):
> On Thu, Dec 15, 2016 at 01:35:14AM +0000, Ian Jackson wrote:
> > I would like a way to get the [In]Release file corresponding to the
> > source from which apt got (or, I guess, would install) a particular
> > package.
> 
> Got vs. would is a HUGE difference – and the information of 'got' is
> not stored anywhere so what you want to know is not possible,
> especially if the system isn't fully upgraded yet and you have to
> consider pinning (ignoring that users could be changing it at
> runtime).  You can approximate all this with guesswork, but the
> amount of times you will guess wrong will make this whole endevour
> borderline useless as a user will never be able to reasonably
> predict what the result of a command issued will be (in my opinion
> at least).

I think it doesn't matter very much whether this new dgit feature gets
"the version I am currently running", or "the version I would get if I
let apt do the update".  If the former information is not recorded
(and I certainly couldn't find it anywhere when I looked) then the
latter will do fine.

As for pinning, I'm not sure exactly why that is a problem, but I
think if the user has specifically pinned the very same package, they
probably have some awareness of what's going on, so bugs where dgit
gives them the wrong suite (or, situations where dgit some something
slightly different to apt) are less bad.

> Johannes Schauer had asked about the inclusion of Release files in
> 'apt-get indextargets' a while ago. It's a slight stretch, but its the
> only place where this would make sense & relatively easy to add.

I think this could be a part of the solution.

> | apt-get indextargets "Created-By: Sources" --format='$(FILENAME) $(CODENAME) $(SUITE)' | while read file codename suite; do
> |   if /usr/lib/apt/apt-helper cat-file "$file" | grep-dctrl -q -PX apt -a -F Version -X '1.4~beta2'; then
> |     echo "FOUND in: $codename ($suite) $file";
> |   fi
> | done

What if the same package is available at the same version in multiple
suites all of which appear in the apt sources ?  I think this is the
part I have to use `apt-cache madison' or `apt show' for.  `apt show'
contains an `APT-Sources' line which I could presumably correlate with
indextargets.

Regards,
Ian.

-- 
Ian Jackson <[email protected]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #29 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Ian Jackson <[email protected]>, [email protected]

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Sat, 31 Dec 2016 02:10:23 +0100

[Message part 1 (text/plain, inline)]

On Mon, Dec 19, 2016 at 01:18:13AM +0000, Ian Jackson wrote:
> I get a sense of puzzlement from your mail.  I will try to explain why
> I want these seemingly-daft things.

My puzzlement comes mostly from you seeming to have a very clear idea
about what you want (= the Origin and Codename field of Release file),
but its completely unclear what you have in hand to get there and why
you actually want those instead of considering other ways.


> Right now, users have to dig a bit to find the right information.
> Take a you look here at the advice under `Finding the Debian release':
>    https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user&apropos=0&sektion=0&manpath=Debian+testing+stretch&format=html&locale=en

(The description of M-A:allowed is wrong – or at least very misleading.
It is neither responsible for the ':i386' nor does it mean that
different builds exists – and libc6 is like the worst possible choice as
an example for an M-A:allowed packages because it neither is one nor can
reasonable be ever be one… It would be /slightly/ more correct with
M-A:same (which libc6 is), but in all honesty that whole sentence hurts
more than it helps – in general that manpage could benefit from review
as it is littered with typos [yuu, teporary, Kf, …] and incorrect or
misleading info [M-A, what you call "alias" is "suite" (or "archive",
but that might confuse people more than it helps), you redefine
"suite", …])

From that I am assuming you have a binary package name as the start.
Good – you can get the installed version (if any) from it, the source
package (and version) it was build from and if you are lucky also the
repository it was downloaded from (if the system is fully up-to-date and
there aren't multiple choices due to multiple versions having the same
number… – a common problem actually with people having a way of easily
building packages with a few additional changes).

You might be unlucky and the user has a version installed which isn't
available (anymore) anywhere as the mirrors carry a new version already
(or she has a previous selfbuilt installed, picks backports by hand, …)
and that is were your trouble begins as things get complicated fast:
binary packages change the source package they belong to (recent
example: gnupg), source packages have a different version than the
binary packages they build (classic example binNMU, but e.g.
libgpg-error used to, too), multiple versions can exist in one
repository, multiple repositories can contain packages with the same
version number (but distinct content), …


btw: Looking at the sources.list is bound to fail. That file might not
even exist on many machines (e.g. on mine) and even if it would many
repositories have a different release schedule then the one they "extend"
(as in you will frequently have them refer to 'oldstable' if you
upgraded to the 'new' stable sooner than the repository owner. A far
more predictable way is e.g. looking at /etc/os-release. dpkg-vendor can
also help you figuring out where you are. Packages itself can also have
an Origin field in the dpkg/status file – that is only used by dpkg
itself ATM through.

The changelog of a package (if available!) can also help you identify
from which pocket it came: "Normal" stable, -security and -backports
have different entry points.

Either seems for me far more simple and reasonable than trying to guess
for each individual package from which repository it eventually came…


Frankly, I have to question the whole interface a bit with its
insistence on ",-security" (and what about -proposed-updates, …) and
a soft suspicion that I can't get Ubuntu sources on Debian or more
delicate: get foodistro/stable and bardistro/stable on Debian/stable as
they all will be "stable" – but I am not a user, I just skimmed the
manpage…

> I would like to make a way to a user to ask dgit for "what I'm
> running" (this request is #848193).
> 
> You mention version numbers.  Obviously the user wants the right
> version.  But the version number is not sufficient.  dgit provides a
> fast-forwarding git branch for each suite.  To get the right history
> structure it is necessary to know not just the sequence of version
> numbers, but also any shared git history (from the dgit git server).
> 
> I think all the information I need is in the Release file (assuming we
> can somehow identify what the right Release file is).  That contains
> both the suite name and the codename, and also the Origin field tells
> us the distro.  (dgit needs configuration for each distro anyway, so
> just the distro name is enough.)

"all information" from the Release files is available via the 'apt-get
indextargets' interface for the relevant files (see next-next section).


> As for pinning, I'm not sure exactly why that is a problem, but I
> think if the user has specifically pinned the very same package, they
> probably have some awareness of what's going on, so bugs where dgit
> gives them the wrong suite (or, situations where dgit some something
> slightly different to apt) are less bad.

You can pin entire suites and some suites come with pins by default,
like experimental. A user will install a package from experimental semi-
explicitly (as depending on the package manager used that might be more
or less easy). Similar for backports. That the user picked a package
from such a suite is lost at the end of the installation. What is
considered a valid upgrade from that version in the future is again
package manager dependent and non-trivial to figure out in the general
case, so if the version you are "running" isn't available online anymore
you are going to either error out or reimplement the logic of your
preferred package manager alienating users of others.

I would envision that as outlined before to be a relatively common
situation in which I have some "old" version installed (which I might
have patched so isn't available online anywhere anyhow) and a new
version is available online I want to patch before installing.


> > Johannes Schauer had asked about the inclusion of Release files in
> > 'apt-get indextargets' a while ago. It's a slight stretch, but its the
> > only place where this would make sense & relatively easy to add.
> 
> I think this could be a part of the solution.
> 
> > | apt-get indextargets "Created-By: Sources" --format='$(FILENAME) $(CODENAME) $(SUITE)' | while read file codename suite; do
> > |   if /usr/lib/apt/apt-helper cat-file "$file" | grep-dctrl -q -PX apt -a -F Version -X '1.4~beta2'; then
> > |     echo "FOUND in: $codename ($suite) $file";
> > |   fi
> > | done
> 
> What if the same package is available at the same version in multiple
> suites all of which appear in the apt sources ?  I think this is the

Nothing protects you from this. You may increase complexity here by
having the same version in multiple repositories – that will also teach
you to stop talking about codenames and suites as if that would exist
for all repositories (or a "correct" Origin value…).

On the upside in the example code I gave all these situations will
produce a line and you can let it give you any info available in the
Release file – I would suggest looking at the output of the command and
the documentation in /usr/share/doc/apt-doc/acquire-additional-files.txt


> part I have to use `apt-cache madison' or `apt show' for.  `apt show'
> contains an `APT-Sources' line which I could presumably correlate with
> indextargets.

Don't use 'apt' in scripts. And as said above all info is available
anyhow so you don't need to correlate anything.


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

Message #34 received at [email protected] (full text, mbox, reply):

From: Ian Jackson <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: [email protected]

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Sat, 31 Dec 2016 01:25:33 +0000

David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or InRelease) file from cache"):
> On Mon, Dec 19, 2016 at 01:18:13AM +0000, Ian Jackson wrote:
> > I get a sense of puzzlement from your mail.  I will try to explain why
> > I want these seemingly-daft things.
> 
> My puzzlement comes mostly from you seeming to have a very clear idea
> about what you want (= the Origin and Codename field of Release file),
> but its completely unclear what you have in hand to get there and why
> you actually want those instead of considering other ways.

I may well be confused or simply wrong, of course.

I get a sense from your mail that I may have irritated you.  I would
be happy to try to talk to you some other way, by phone perhaps.
That's often a better approach than writing long emails to try to sort
out someone's misunderstanding.  Or if you think it would help, we
could ask someone else to try to help deconfuse our conversation.

If you'd like to try a phone call or something, please send me some
details (eg, availability, timezone, location) by private email.

Otherwise I can try to explain again why I think I need the suite
codename, and try to explain my thinking about some of the things that
seem wrong to you.

Thanks,
Ian.

-- 
Ian Jackson <[email protected]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #39 received at [email protected] (full text, mbox, reply):

From: David Kalnischkies <[email protected]>

To: Ian Jackson <[email protected]>

Cc: [email protected]

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Wed, 4 Jan 2017 17:03:56 +0100

[Message part 1 (text/plain, inline)]

On Sat, Dec 31, 2016 at 01:25:33AM +0000, Ian Jackson wrote:
> David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or InRelease) file from cache"):
> > On Mon, Dec 19, 2016 at 01:18:13AM +0000, Ian Jackson wrote:
> > > I get a sense of puzzlement from your mail.  I will try to explain why
> > > I want these seemingly-daft things.
> > 
> > My puzzlement comes mostly from you seeming to have a very clear idea
> > about what you want (= the Origin and Codename field of Release file),
> > but its completely unclear what you have in hand to get there and why
> > you actually want those instead of considering other ways.
> 
> I may well be confused or simply wrong, of course.
> 
> I get a sense from your mail that I may have irritated you.  I would

You haven't, which kinda is the "problem": I am not a packager, so
I don't have the problems a packager has and hence I don't have
a particular interest nor the possibility to really judge the solution.
My entire knowledge of dgit and the problems it solves are hence based
on your bugreport and the manpage you referred to. That isn't a lot, so
in my mind I replace dgit with 'apt source' and imagine wanting to
implement such a feature for that.

What I can judge is the manpage on a textual content level (which was
orthogonal to the discussion at hand and hence only a sidenote in
brackets) and the perceived notion that it is easy to map binary package
↔ source package ↔ repository – which while it looks simple enough is
a horrible tangled mess as soon as you hand it to users as a xkcd#1172
reference lurks behind every corner.  Everyone who intends to move in
that direction and wants to hear it is hence warned by me that there not
only be dragons, but madness, with examples they might not have
considered.

I can't stop the adventurers of course, but causing them to recheck what
they have, what they want to achieve and how they want to do that tends
to be a good use of time for them before they enter the dungeon. I can't
really help with that through as they, like in your case, come from far
away 'kingdoms' I don't know.


> If you'd like to try a phone call or something, please send me some

(No I don't: I don't really have a phone [or something similar for that
matter] nor do I like using them for plenty personal off-topic reasons)


> Otherwise I can try to explain again why I think I need the suite
> codename, and try to explain my thinking about some of the things that
> seem wrong to you.

You don't need to. It is enough if you know the answer – I don't need to
know, for me its enough if someone knows. I was 'only' advising against
rushing into it, but I also said how you can do it prepared: 'apt-get
indextargets' should be your information source as it is output meant to
be parsed – 'apt-cache madison' is not – and also neatly solves the
problem of finding and parsing Release files, as the data is already
included so that they don't need to be parsed.

If there is something unclear ask, but make sure to read the
documentation for indextargets as it details value meaning and
availability of fields.


The bugreport here will be used for having the 'Release' file be part of
that interface itself. In all likelihood that will be well after stretch
through as we should first solve the problem of having InRelease
sometimes called Release… but that isn't blocking you as the bits you
want from it are available 'elsewhere' already.


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

Message #44 received at [email protected] (full text, mbox, reply):

From: Ian Jackson <[email protected]>

To: David Kalnischkies <[email protected]>

Cc: [email protected]

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Wed, 4 Jan 2017 16:31:49 +0000

David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or InRelease) file from cache"):
> On Sat, Dec 31, 2016 at 01:25:33AM +0000, Ian Jackson wrote:
> > I get a sense from your mail that I may have irritated you. 
> 
> You haven't,

OK, good.

> > Otherwise I can try to explain again why I think I need the suite
> > codename, and try to explain my thinking about some of the things that
> > seem wrong to you.
> 
> You don't need to. It is enough if you know the answer – I don't
> need to know, for me its enough if someone knows. I was 'only'
> advising against rushing into it,

Well, I don't want to implement something wrong.  You know much more
than I do about the way apt chooses which package to get from where.

I don't want to impose on your time but if you're willing I still feel
there is room for me to get to a better understanding about what dgit
ought to do in this area.

So in that spirit:

> My entire knowledge of dgit and the problems it solves are hence based
> on your bugreport and the manpage you referred to. That isn't a lot, so
> in my mind I replace dgit with 'apt source' and imagine wanting to
> implement such a feature for that.

The most salient difference is that dgit needs to choose a git branch
name.  dgit's usual approach is to name branches after suite codenames
(eg `refs/heads/dgit/jessie').  Each of these branches is
fast-forwarding (by use of pseudomerges[1] if necessary).

If the user says `dgit clone dpkg RUNNING' dgit has not only to
generate a git tree, once off, the same way `apt source' would
generate an unpacked source tree.  It also has to put that new git
working tree on a particular branch.  Then, in future, a suitable
`dgit pull' rune ought to update that branch.

Suppose that in between `dgit pull' runs, the user does `apt-get -t
jessie-backports install dpkg' and then `apt-get -t jessie install
dpkg'.  I don't think the user wants a single git branch which
contains a fast forwarding sequence of commits whose contents flap
between jessie and jessie-backports.

Rather, jessie-backports ought to be its own git branch.  

The user who switches between jessie and jessie-backports for a
package should see those as two git branches, which they are looking
at alternately.

This is why the version number, or the .dsc, is not sufficient.  We
want something with some kind of historical continuity.  The suite is
a thing which exists outside the user's system and contains a series
of updates for particular package(s) - ie, conceptually is very like a
branch.  (Indeed the Debian BTS calls them `branches'.)

Does that make sense ?

> The bugreport here will be used for having the 'Release' file be part of
> that interface itself. In all likelihood that will be well after stretch
> through as we should first solve the problem of having InRelease
> sometimes called Release… but that isn't blocking you as the bits you
> want from it are available 'elsewhere' already.

Thanks.  I think this will all have to wait until after stretch in any
case.

Ian.

[1] A `pseudomerge' is a merge which exists not to change the code but
only to make a branch fast-forwarding.  Its tree is identical to that
of one of its parents; the others do not contribute to the contents at
all.  Eg, the result of `git merge -s ours'.

-- 
Ian Jackson <[email protected]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Message #49 received at [email protected] (full text, mbox, reply):

From: Colin Watson <[email protected]>

To: Ian Jackson <[email protected]>, [email protected]

Cc: David Kalnischkies <[email protected]>

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Tue, 19 Mar 2024 16:51:35 +0000

Hi,

I don't know if it helps or hinders this bug since I have rather
different reasons from Ian, but I found myself looking at this bug today
because I also wanted a way to get hold of an [In]Release file.  The
difference is that I'm not trying to get hold of it for a particular
package, but for (roughly) a sources.list entry; but all my other
requirements seem basically the same as Ian's.  My use case is as
follows, and you can tell me if it's too different to include in the
same report:

 * In order to be able to implement an "import the contents of this
   repository into our database" task in debusine
   (https://freexian-team.pages.debian.net/debusine/), I want to
   discover which architectures are supported by a given suite in a
   repository, assuming that it has at least a Release file.  And of
   course then I want to be able to fetch all the files, but at least
   that part isn't so hard.

 * If you already know which architectures you want, then this is easy.
   But if you want to ask the repository which architectures it
   supports, as far as I know the only sensible way is to consult the
   Release file.

 * Acquiring and verifying Release files correctly is, as I'm sure you
   know, challenging.  I would like to avoid writing my own code to call
   gpgv in just the right way (again).  I've been here before with
   #918304.

 * I'd hoped to use python-debian, but its GPG verification support is
   currently not as good as it should be (#710923) and in any case what
   you get from its Release file handling is not very helpful
   (#1067160).

 * So I looked at apt/python-apt.  I know how to instantiate a temporary
   apt cache with its own configuration (in the manner of chdist(1), for
   instance), and if I could discover the available architectures after
   an initial fetch then I could call "apt-get update" a second time
   with APT::Architectures set and then I'd have everything.  However,
   given a cache, I seem to be able to access basically everything
   _except_ for the Release file in documented ways.  As mentioned in
   this bug, "apt-get indextargets" omits the Release file.

For now, I'll probably dodge the problem by requiring the user to
specify which architectures they want, and then I don't need the Release
file.  But I feel like I'm missing something.

Thanks,

-- 
Colin Watson (he/him)                              [[email protected]]

Message #54 received at [email protected] (full text, mbox, reply):

From: Julian Andres Klode <[email protected]>

To: Colin Watson <[email protected]>, [email protected]

Cc: Ian Jackson <[email protected]>, David Kalnischkies <[email protected]>

Subject: Re: Bug#848194: Want way to get Release (or InRelease) file from cache

Date: Tue, 19 Mar 2024 18:22:15 +0100

On Tue, Mar 19, 2024 at 04:51:35PM +0000, Colin Watson wrote:
> Hi,
> 
> I don't know if it helps or hinders this bug since I have rather
> different reasons from Ian, but I found myself looking at this bug today
> because I also wanted a way to get hold of an [In]Release file.  The
> difference is that I'm not trying to get hold of it for a particular
> package, but for (roughly) a sources.list entry; but all my other
> requirements seem basically the same as Ian's.  My use case is as
> follows, and you can tell me if it's too different to include in the
> same report:
> 
>  * In order to be able to implement an "import the contents of this
>    repository into our database" task in debusine
>    (https://freexian-team.pages.debian.net/debusine/), I want to
>    discover which architectures are supported by a given suite in a
>    repository, assuming that it has at least a Release file.  And of
>    course then I want to be able to fetch all the files, but at least
>    that part isn't so hard.
> 
>  * If you already know which architectures you want, then this is easy.
>    But if you want to ask the repository which architectures it
>    supports, as far as I know the only sensible way is to consult the
>    Release file.
> 
>  * Acquiring and verifying Release files correctly is, as I'm sure you
>    know, challenging.  I would like to avoid writing my own code to call
>    gpgv in just the right way (again).  I've been here before with
>    #918304.
> 
>  * I'd hoped to use python-debian, but its GPG verification support is
>    currently not as good as it should be (#710923) and in any case what
>    you get from its Release file handling is not very helpful
>    (#1067160).
> 
>  * So I looked at apt/python-apt.  I know how to instantiate a temporary
>    apt cache with its own configuration (in the manner of chdist(1), for
>    instance), and if I could discover the available architectures after
>    an initial fetch then I could call "apt-get update" a second time
>    with APT::Architectures set and then I'd have everything.  However,
>    given a cache, I seem to be able to access basically everything
>    _except_ for the Release file in documented ways.  As mentioned in
>    this bug, "apt-get indextargets" omits the Release file

Sorry I'm afraid this is not exposed in the apt code. There is only a
function to check which architectures are supported but you can't get
a list.

Meanwhile apt-get indextargets omits release files by design as they
are not indextargets, but uh metaindex targets.

python-apt omits bindings for ReleaseFile, there really should be
a Cache.release_files list of release file objects. You'd still need
to parse them yourself because we don't have the data in the cache
but that will get you most of the way there.

You may also for now rely on the file matching *Release in the lists
dir.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Send a report that this bug log contains spam.