$SRCDEST versus $startdir for configurable builds

Stebalien · 2013-08-12 23:29:14

According to one of gtmanfred's comments on dunst, PKGBUILDS should use $SRCDEST instead of $startdir when referring user replaceable build-time config files (config.h, kernel configs, etc). Is there a general consensus on this? Unless I am mistaken, this variable exists so that users can cache downloaded source files outside of the main package directory. I understand that $startdir is generally considered deprecated but would this be a reasonable use case.

jasonwryan · 2013-08-12 23:37:31

It still appears in core packages; and namcap complains about the error:

PKGBUILD (linux) E: File referenced in $startdir

WonderWoofy · 2013-08-12 23:48:32

jasonwryan wrote:

It still appears in core packages; and namcap complains about the error:
PKGBUILD (linux) E: File referenced in $startdir

The reason why I think that this isn't big deal (yet?), is that there are quite a lot of packages that have been recently updated that still have this "issue". Maybe some time in the future there will be movement toward the new standard, but as it is now, I wouldn't worry about it too much. We seem to be in a transitional stage. So if you are writing a new PKGBUILD, then maybe use the new way. But if you have an existing one, it is probably not work bumping the pkgrel just to change this.

Allan · 2013-08-13 00:11:32

As far as I am concerned, $SRCDEST and $startdir should never be used in a PKGBUILD. If you are using them, you are probably doing something wrong...

Ledti · 2013-08-13 00:17:05

Hrm. I didn't know about $SRCDEST... two of my AUR packages use $startdir and until just now I thought that it was the only sane/safe way to get to the base PKGBUILD directory. I'm not sure if I agree with with using $SRCDEST for scenarios where the PKGBUILD wants to copy config.h and other commonly named files. Couldn't they conflict if a user set $SRCDEST in makepkg.conf?

$startdir seems more appropriate even though it's intended to be deprecated.

edit: here's an example PKGBUILD which uses $startdir.

It's nifty because the user can download the tarball and run makepkg -o (since it's in the prepare function), edit the config.h, then run makepkg -si to build and install. You no longer have to worry about your config.h being overwritten or manually copying it.

Last edited by Ledti (2013-08-13 00:26:43)

Stebalien · 2013-08-13 01:17:27

Allan wrote:

As far as I am concerned, $SRCDEST and $startdir should never be used in a PKGBUILD. If you are using them, you are probably doing something wrong...

This makes sense for packages pushed to binary repositories but it can be useful to allow AUR users to customize statically configured programs (sxiv, dwm, etc) at build time. Can you recommend an alternative solution?

Allan · 2013-08-13 03:22:49

Include the modifiable file in the source and use "SKIP" as the md5sum.

Stebalien · 2013-08-13 20:50:31

That would mean that the file would need to exist in the package itself and updating the package using a tool like cower would overwrite it. This would also force the maintainer to keep the default config provided in the package in sync with the default config provided upstream (an additional failure mode).

Another solution is to get TUs to agree on a user package config directory (~/.config/packages/<pkg>/...). Or just make a makepkg wrapper that calls `makepkg -o`, <custom prepare stuff>, `makepkg -e`.

Arch Linux

#1 2013-08-12 23:29:14

$SRCDEST versus $startdir for configurable builds

#2 2013-08-12 23:37:31

Re: $SRCDEST versus $startdir for configurable builds

#3 2013-08-12 23:48:32

Re: $SRCDEST versus $startdir for configurable builds

#4 2013-08-13 00:11:32

Re: $SRCDEST versus $startdir for configurable builds

#5 2013-08-13 00:17:05

Re: $SRCDEST versus $startdir for configurable builds

#6 2013-08-13 01:17:27

Re: $SRCDEST versus $startdir for configurable builds

#7 2013-08-13 03:22:49

Re: $SRCDEST versus $startdir for configurable builds

#8 2013-08-13 20:50:31

Re: $SRCDEST versus $startdir for configurable builds

Board footer