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

Groups > linux.debian.devel > #119667

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

Show all headers | View raw

* 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

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