the PKGBUILD standard features vs. bash "backdoors"

imrehg · 2009-01-19 14:39:52

Hi,

Lately I was trying to make a few packages to put on AUR, for which I've been reading quite a few PKGBUILDs from official packages and from forums/bug tracker...

It feels to me that even if e.g. it is explicitly required by AUR, that the packages follow the packaging standards, the standards themselves are not completely defined. What I mean is that it is well defined, what a PKGBUILD can do to the system it is installed (where to put things, where not), but the actual structure of PKGBUILDs is not described in a way, that it is unambiguous. At least I couldn't find any place like that, if anybody knows, please direct me there (i looked on the wiki and in the man pages so far).

Because of this lack of definition and some practices of the official packages, users learning the packaging come across and adopt a lot of "tricks", that rely on the fact that makepkg is a bash script, just "sourcing" the PKGBUILD - just as another bash script.
To give two examples:
- using things like "eval source=..." to put multiple source files without the need of... I donno, a few copy-pastes? (e.g. extra/firefox-i18n)
- comments in variable fields (since the bash script will throw out everything on the right if encoutners a # sign) (core/kernel26)

I'm not against such tricks in general - if they are documented and accepted. I thought one strength of the PKGBUILD format is, that there could be alternative implementations, as longs as they do the same thing. And indeed, there's at least two implementation: besides makepkg, the parser on AUR has to be able to read the same PKGBUILDS...... And who knows, maybe someone will come up with a better makepkg? Then these packages should still work. Quirks are alright, as long as people can plan for it.
At the moment, what should we say to the person who's asking why AUR cannot parse a package that is modelled exactly after a package in extra (e.g. FS#12645 - eval source don't work in AUR)?
Handling the comments was implemented recently, but it needed trial and error to get the right behaviour, since it is not documented and indeed why should someone writing a PKGBUILD know what program will parse it?

Thus I propose a revision of the PKGBUILD format, unambiguously defining accepted behaviour (once again I'm absolutely not against including any quirks as long as they are _included_), and having a more rigorous check whether official packages follow the definition. On our, self-checking would probably work, if any package breaks, there would be a document to point any newbie to.

I have to say, I don't suggest writing a new makepkg. Not at the moment. Just some improvement, to make things more transparent and simple.

Otherwise: man, pacman is awesome.
Cheers....

Allan · 2009-01-19 14:49:50

PKGBUILDs are bash scripts. That is the foundation of their simplicity. This way, the build function is exactly what you would type manually to install a package. So if something other than makepkg needs to parse them, it should use a bash wrapper that reads them in and outputs the needed data in a nice format to be read in. That is what namcap does to get the data into a python script.

imrehg · 2009-01-19 15:10:44

I'm not talking about the build() part - that's the simplest, exact bash, no argument about it, it's perfect for the goal.

What I mean, how the REST of the PKGBUILD is handled: should the rest of the variables ( source=, depends=,....) be bash as well, or should it be, as I think intended, barely a list of values with substitution from other, previously defined variables?
Because if they are bash as well, should we document all the possible behavours with e.g. eval and comments and such (many things I don't know)? How about if someone is doing other bash - for whatever reason - outside of the build()? Should that be suppressed or let through, like now (i think)? That's the part I was thinking about.

Allan · 2009-01-19 15:19:32

I think my build() example detracted from my point. The whole PKGBUILD script is bash. It is made to be sourced by bash. If it is sourced, runs and makes a valid package with makepkg then it is a valid PKGBUILD. If some non-bash program wants to parse the PKGBUILD, it needs to understand bash or use a wrapper to get it in the right format. Tricks like

${pkgver//./-}

are useful when upstream uses "-" instead of "." in their source file versions. Given PKGBUILDs are bash, we can use these.

imrehg · 2009-01-19 15:29:47

Okay, this is a completely valid answer, even if it is probably not exactly the one I hoped for.

Then basically AUR also should be a complete bash parser, otherwise most of its features are essentially useless, since packages from core & extra (& community?) - the ones people are encouraged to model their packages - couldn't ever be correctly parsed. If it is the case, that's already a good thing to know because it affects the whole design.
And if this is the attitude towards PKGBUILD functionality, that "whatever works with makepkg", than write THIS in the man page, since the currently laid out structure for the script is then not requirement - it's merely a suggestion.

I just feel most of the things that currently use "tricks" can be done using only the basic functionality - maybe a bit more work and paying attention needed, but any PKGBUILD should be checked carefully anyway. And it has to be done only once on update, after that no matter if it is built 1 or 10000 times, makepkg doesn't care whether it is done with tricks or "properly". So why not do it properly?

Shingoshi · 2009-02-01 21:13:50

It would be really helpful to have a standard by which all PKGBUILD scripts are evaluated. Not having a standard can only lead to the kind of confusion that's posted here. For something like an Automated Build System that I've proposed (http://bbs.archlinux.org/viewtopic.php? … 75#p491175), a uniform standard would be required not optional. The amount of confusion stemming from an ad hoc assortment of whatever works, would make an automatic build system unworkable.

If there were scripts as well defined as provided by this src2pkg (http://distro.ibiblio.org/pub/linux/dis … rch-17.tgz) package building tool, there would be no confusion. And it would work just fine for ArchLinux.

It should also be pointed out, that this is one of the safest build tools available. Since every package is built by the normal user, and then installed as root. The / filesystem stands little chance of ever being corrupted. No need for chroots.

Xavian-Anderson Macpherson
Shingoshi

Last edited by Shingoshi (2009-02-01 21:25:26)

Arch Linux

#1 2009-01-19 14:39:52

the PKGBUILD standard features vs. bash "backdoors"

#2 2009-01-19 14:49:50

Re: the PKGBUILD standard features vs. bash "backdoors"

#3 2009-01-19 15:10:44

Re: the PKGBUILD standard features vs. bash "backdoors"

#4 2009-01-19 15:19:32

Re: the PKGBUILD standard features vs. bash "backdoors"

#5 2009-01-19 15:29:47

Re: the PKGBUILD standard features vs. bash "backdoors"

#6 2009-02-01 21:13:50

Re: the PKGBUILD standard features vs. bash "backdoors"

Board footer