search

falconindy / expac

alpm data extraction utility
91 stars 15 forks source link

Add a new formatter for pkgbase. #20

Closed Earnestly closed 8 years ago

Earnestly commented 9 years ago

Since pacman 4.2 now exposes the pkgbase via .PKGINFO and desc(?), would it be possible to add a new formatter for expac to let us determine the pkgbase for a split-package?

Such as %c or one of AHIJKUWXYZceqyz perhaps.

[My assumption on pkgbase being exposed might be wildly wrong.]

kyrias commented 9 years ago

The pkgbase has been in .PKGINFOsince 2009, though not yet in desc, though that part was easy to add too. Now I just have to figure out what I did to make -Qi segfault on me.

falconindy commented 9 years ago

I think you're confusing "pkgbase" in the SRCINFO file with %PKGBASE% in the desc DB file. As Johannes points out, this isn't anything new with pacman 4.2.

More to the point, if you want this in expac, you'll have to add an accessor method to the ALPM API first.

Earnestly commented 9 years ago

Yes, you're right. My meaning was that it's now exposed in a way that lets me programmatically figure out the "pkgbase" via the package's name, this being %BASE% or %PKGBASE% which wasn't easily(?) possible before. (gcc-fortran's desc doesn't mention a base package.)

My immediate usecase would be for using git to pull down the source files from the svntogit repos. The idea would be to check with expac if the package in question is actually part of a splt-package and use the "pkgbase" instead of the "pkgname". Either that or pull it out of the desc files.

N.b. this is based on Allan claiming it was exposed which it may not, at least I can't find any indication of it existing in the pacman code base, so he may have lied or being drunk.

falconindy commented 9 years ago

My immediate usecase would be for using git to pull down the source files from the svntogit repos.

Hrmm, well, if the pkgbase always matches the directory in ABS, I think that's probably just a coincidence. I'm not sure that's actually enforced anywhere. If you really wanted to rely on that, I'd strongly suggest:

1) auditing the current world 2) submitting changes to devtools/db-scripts to enforce this