Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #119666
| 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 |
[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
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