[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver) mapping?



Am Fri, Nov 21, 2025 at 05:22:23PM +0100, schrieb Mihai Moldovan:
> Have a I missed anything and just not looked deeply enough into AptPkg, or
> is what I want to do really impossible?

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


That said, if you can access the underlying text of a pkgRecord of
the binary package you can work with the general rules:
1. If there is no "Source:" tag, source package has the same name as the
   binary package and the same version
2. If there is a tag in the form "Source: srcpkgname" the name of the
   source package is 'srcpkgname', while the version is the same.
3. If the tag looks like "Source: srcpkgname (version)" you have all
   the information contained in it.

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.


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.


Maybe instead of following the rules I outlined above, you can patch the
perl binding to give you access to the fields in the binary cache. I am
sure Brendan O'Dea would be happy for any help (cc'ed).


Best regards

David Kalnischkies

Attachment: signature.asc
Description: PGP signature


Reply to: