Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver) mapping?
* On 11/21/25 18:20, David Kalnischkies wrote:
> I can't speak to the perl bindings, never having really written any
> perl, but I suspect that this is simply missing from the bindings as
> they haven't seen much development in (recent) years.
>
> I moved this particular information to the binary cache for easier
> access in 2014, but I am not sure if that was ever adapted for perl
>
https://salsa.debian.org/apt-team/apt/-/commit/a221efc331693f8905da870141756c892911c433
It looks like SourceVer has been part of the Record parser since 2007:
https://salsa.debian.org/apt-team/apt/-/commit/c2f2b86252cec3a9ec68df2f55850067faa705d6
I figure all that is missing would be a
PUSH_PAIR (p, SourceVer);
in
https://salsa.debian.org/bod/libapt-pkg-perl/-/blob/master/AptPkg.xs?ref_type=heads#L1233
.
I'll have to test that.
Unfortunately, even if it can be added, it won't fix my immediate need (naturally).
> That said, if you can access the underlying text of a pkgRecord of
> the binary package you can work with the general rules:
> [...]
>
> That is certainly possible and what many tools did and still do if they
> need this information – and can live with the associated cost if they do
> need it: As in looking up the Packages file the stanza is contained in,
> parsing it and spewing it out.
Technically, the Perl bindings do give me the package index file for a given
bin:pkg name-version combination and it specifies an offset, so I probably
should be able to extract the needed information out of that.
Or, probably even easier, I could shell out to "apt-cache show name=ver" and
parse the Source: tag with the rules you suggested.
What I meant when I wrote "impossible" really was "impossible with the
high-level abstraction the AptPkg Perl bindings provide", which sadly seems to
be true for now.
I'll see what I can do about getting this information into the Perl bindings as
well, given that it seems to be really easy to do.
> Note that additional changes to src <-> bin mapping were made as recent
> as this year in libapt, but I suppose those mainly concern the other way
> around: You have a source package name and want to find the binary
> packages built from it.
This is certainly also very useful to have, but nothing I'd strictly need (right
now, at least). A bidirectional mapping is still something that probably is
often needed if you're working with source packages.
Mihai
Reply to: