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

Groups > linux.debian.devel > #119665 > unrolled thread

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

Back to article view | Back to linux.debian.devel

Contents

  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

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

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

Hello fellow developers


I'm currently using the Perl AptPkg bindings to read and handle package cache 
metadata.

I'd like to map a bin:pkg name and version to its corresponding src:pkg ame and 
version, but unless I missed something, this doesn't seem to be possible?

Mapping a bin:pkg name to a src:pkg is easy, through AptPkg::Source(->find), but 
getting the correct version seems to be impossible.

Generally, binary and source package versions may not be identical, e.g., lvm2 
-⁠> dmsetup.

While AptPkg::Source->find will return a list of source packages for a given 
binary package, if the list contains multiple entries, there's no way to tell 
which entry might be a appropriate for a given bin:pkg version, since while the 
AptPkg::Source data contains a list of bin:pkgs, these are unversioned.

Likewise, looking up an AptPkg::Cache::VerFile object via 
AptPkg::PkgRecords-⁠>lookup will return a SourcePkg hash field, but the data in 
there is also just the unversioned source package name.


Contrary to that, the apt_pkg python bindings do provide a source_ver method as 
part of its PackageRecords class, which is pretty much exactly what one would need.


Have a I missed anything and just not looked deeply enough into AptPkg, or is 
what I want to do really impossible?




Mihai

[toc] | [next] | [standalone]

#119666

[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

[toc] | [prev] | [next] | [standalone]

#119667

* 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

[toc] | [prev] | [next] | [standalone]

#119668

* On 11/21/25 18:47, Mihai Moldovan wrote:
> 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.

Yep, this is doing exactly what I expected and would need.

Good to know that it's as easy as that!



Mihai

[toc] | [prev] | [next] | [standalone]

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

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

https://salsa.debian.org/bod/libapt-pkg-perl/-/commit/59ff74eb7f513fe0436087c26996dbfdfb0127cd

On Sat, 22 Nov 2025 at 05:10, Mihai Moldovan <ionic@ionic.de> wrote:

> * On 11/21/25 18:47, Mihai Moldovan wrote:
> > 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.
>
> Yep, this is doing exactly what I expected and would need.
>
> Good to know that it's as easy as that!
>
>
>
> Mihai
>

[toc] | [prev] | [next] | [standalone]

#119746

* On 11/22/25 11:46, Brendan O'Dea wrote:
> https://salsa.debian.org/bod/libapt-pkg-perl/-/ 
> commit/59ff74eb7f513fe0436087c26996dbfdfb0127cd <https://salsa.debian.org/bod/ 
> libapt-pkg-perl/-/commit/59ff74eb7f513fe0436087c26996dbfdfb0127cd>

Thank you very much! Of course, I did forget about the test cases...



Mihai

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web