A discussion about universally/programmatically parsable PKGBUILDs.

Xyne · 2009-08-09 04:16:00

oopsicrappe wrote:

For the purpose of uniting buildscripts for different distros, you might be better off starting from scratch than adapting the PKGBUILD. You would probably need a lot more flexibility than PKGBUILDs offer, for instance it would be useful to have something like Gentoo's USE flags so different distros could easily enable different compile time options globally. It would also be useful to be able to enable and disable different patches in the buildscript. Some sort of unified buildscript would be great, but it probably would be difficult to convince everyone to use it. Good luck!:)

This is the kind of input that I'm looking for in this thread (constructive criticism, suggestions, caveats, etc). Thanks.

I started with the idea of PKGBUILDs for a few reasons:
*) I think Arch's packaging system benefits immensely from simplicity and versatility.
*) I don't have any experience packaging for other distros so I'm not really aware of their systems
*) I would want this to work on Arch if anything because that's what I use... the possibility of other distros using it is a wistful afterthought and nothing more at the moment

The current idea though does make it possible to have different build scripts per distro and to add custom variables such as USE flags. I haven't given the build function much thought yet which is why it's still treated as a monolithic verbatim block. Ideally it would be possible to select patches, use different configuration options, etc automatically using configuration files. This might be possible within a limited context using different build functions (distro-specific in the PKGBUILD, user-specific in local configuration files) but I'm not sure.

*heads off with this in mind*

shining · 2009-08-09 08:10:57

Maybe it is worth studying packaging formats of other distros.
I would guess most of them are better than PKGBUILDs on the universally/programmatically parsable side.
Just to check you are not re-inventing something that already exists, or trying to solve a problem already solved

shining · 2009-08-10 20:57:51

I also wanted to say that I completely understand the motivation behind this.

namcap does it the "source way". Since it only sources one package at a time, it can at least do this in a limited and rather secure env : http://projects.archlinux.org/?p=namcap … ld;hb=HEAD

I worked on a tool to do several integrity checks on a tree of PKGBUILD (including dep checking). The original tool attempted to parse bash, but it had several bugs and limitations, so I wanted to rewrite it and do the namcap way. However, for performance reason, I couldn't do one fork/bash call for each PKGBUILD, but this means I could no longer do it in a secure environment (otherwise I would need to put all PKGBUILDs in the same directory to be able to source them or some other crazyness) :
http://projects.archlinux.org/?p=dbscri … sh;hb=HEAD

and now I just realized it is completely broken because of split packages (and to a 'lesser' extent any packages) :
http://www.archlinux.org/pipermail/arch … 12830.html

I didn't spend enough time to know how difficult it is to support, but it probably means I will have to re-use some parts of makepkg (like backing/restoring variables), and my parse_pkgbuilds.sh will be much more complex.

Arch Linux

#51 2009-08-09 04:16:00

Re: A discussion about universally/programmatically parsable PKGBUILDs.

#52 2009-08-09 08:10:57

Re: A discussion about universally/programmatically parsable PKGBUILDs.

#53 2009-08-10 20:57:51

Re: A discussion about universally/programmatically parsable PKGBUILDs.

Board footer