Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.devel > #119666

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

From David Kalnischkies <david@kalnischkies.de>
Newsgroups linux.debian.devel
Subject Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver) mapping?
Date 2025-11-21 18:30 +0100
Message-ID <LTD7j-eGdJ-1@gated-at.bofh.it> (permalink)
References <LTCkV-eFFX-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver)  mapping? Mihai Moldovan <ionic@ionic.de> - 2025-11-21 17:40 +0100
  Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver)  mapping? David Kalnischkies <david@kalnischkies.de> - 2025-11-21 18:30 +0100
    Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver)  mapping? Mihai Moldovan <ionic@ionic.de> - 2025-11-21 18:50 +0100
      Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver)  mapping? Mihai Moldovan <ionic@ionic.de> - 2025-11-21 19:20 +0100
        Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver) mapping? "Brendan O'Dea" <bod@debian.org> - 2025-11-22 11:50 +0100
          Re: Perl AptPkg bindings: no binpkg(name, ver) -> srcpkg(name, ver)  mapping? Mihai Moldovan <ionic@ionic.de> - 2025-11-26 15:50 +0100

csiph-web