[Solved] Location of user config.h files in PKGBUILDS

jasonwryan · 2014-03-03 00:33:26

This picks up some of the discussion in this thread.

There are quite a few lightweight utilities in AUR that are only customisable by editing config.h and then recompiling. Most, if not all PKGBUILDS deal with this in one of two ways, using $startdir (now deprecated) or $srcdest (an abuse of that variable), like so:

 if [[ -f $SRCDEST/config.h ]]; then
  msg "Using custom config.h"
  cp $SRCDEST/config.h config.h
fi

One, eminently sensible approach, suggested to me by HalosGhost, is to use $XDG_CONFIG_HOME for these files. This would eliminated the {ab}use of those variables, place the user configuration files where such files belong and probably make VCS management of the files easier for people.

Do people see a downside to this? Is there a better approach?

While I like the idea in principle, I still feel slightly uneasy about separating out the header files from the build directory and am conscious that it is a departure for an established (even if munted) convention.

Thoughts?

Trilby · 2014-03-03 00:40:32

A couple of my packages check $XDG_CONFIG_HOME (due to H.G.'s suggestion/contribution). But these are just checks. If the directory and/or file does not exist, there is a default config.h that is used to have "sensible" defaults to the package will compile and function just fine without the user having their own config.h in $XDG_CONFIG_HOME.

One criticism of this is in the view that PKGBUILDS should build the same package on any machine (except for architecture). Though this goal is already not met: a user can specify their own build flags in /etc/makepkg.conf, so two users will build two different packages from the same PKGBUILD already. If /etc/makepkg.conf can lead to different builds, I don't see how $XDG_CONFIG_HOME/<pkg>/config.h leading to different packages would be a concern. So long as the PKGBUILD builds without this file (e.g. in a clean chroot), this seems fine to me.

HalosGhost · 2014-03-03 00:44:47

jwr, thanks for starting the conversation again. i feel like this one is an important one to have.

For people that feel worried about pushing the XDG standard, perhaps it would be easier to offer a default directory if the XDG standard isn't met:

if [[ -f "${XDG_CONFIG_HOME:=$HOME/.config}/${pkgname}/config.h" ]]; then
    msg "Using custom config.h"
    cp "${XDG_CONFIG_HOME:=$HOME/.config}/${pkgname}/config.h" .
fi

This way, if XDG_CONFIG_HOME isn't set, then it will look for $HOME/.config/${pkgname}/config.h. It seems like a perfect compromise to me.

The argument for this practice overall is that, if a program is configured at compile-time through a config.h, then it's a config that the user is meant to customize. Therefore, it should be kept with other per-program config files. I find this method to be much cleaner, but I'm open to criticism.

All the best,

-HG

Trilby · 2014-03-03 01:01:23

HalosGhost wrote:

... then it's a config that the user is meant to customize.

This may be questionable though - particularly on a multi-user system. Should a binary installed in /usr/bin/ be built against something in /home/<user>/? From a strict point of view /etc/<pkgname>/ would seem like a better place - but from a practical point of view that doesn't seem appealing.

Last edited by Trilby (2014-03-03 01:01:54)

WorMzy · 2014-03-03 01:10:10

Clean chroots don't know about $XDG_CONFIG_HOME.

IMO, configuration of these programs should be done in the prepare function in the PKGBUILD, using patches or sed statements. Where this is cumbersome, the replacement config.h should be included in the sources array, and moved into place during the prepare function.

I also feel that the upstream projects should be petitioned to make their programs more easily configurable post-compilation, though I can see why this would prove unpopular..

HalosGhost · 2014-03-03 01:20:50

Trilby wrote:

This may be questionable though - particularly on a multi-user system. Should a binary installed in /usr/bin/ be built against something in /home/<user>/? From a strict point of view /etc/<pkgname>/ would seem like a better place - but from a practical point of view that doesn't seem appealing.

Valid point, but then, Arch expects each user to be their own sysadmin. So the line is blurred a bit.

WorMzy wrote:

IMO, configuration of these programs should be done in the prepare function in the PKGBUILD

Actually, the proposal above would put these checks in the prepare() function.

Putting the config.h in the source array is valid, but then it requires the config to be there rather than allowing for it. The above check would copy the config if it exists, and if it does, it would use it. If not, it uses the defaults.

All the best,

-HG

Allan · 2014-03-03 02:25:54

Add it as a source file for the user to provide in the PKGBUILD with "SKIP" in the md5sums field. The packager should provide a default config file.

jasonwryan · 2014-03-04 02:10:26

After tinkering around a bit, I agree with WorMzy and Allan: I'm going to use this approach for the few packages I look after:
https://aur.archlinux.org/packages/sx/sxiv-git/PKGBUILD

Thanks for the feedback and suggestions.

Arch Linux

#1 2014-03-03 00:33:26

[Solved] Location of user config.h files in PKGBUILDS

#2 2014-03-03 00:40:32

Re: [Solved] Location of user config.h files in PKGBUILDS

#3 2014-03-03 00:44:47

Re: [Solved] Location of user config.h files in PKGBUILDS

#4 2014-03-03 01:01:23

Re: [Solved] Location of user config.h files in PKGBUILDS

#5 2014-03-03 01:10:10

Re: [Solved] Location of user config.h files in PKGBUILDS

#6 2014-03-03 01:20:50

Re: [Solved] Location of user config.h files in PKGBUILDS

#7 2014-03-03 02:25:54

Re: [Solved] Location of user config.h files in PKGBUILDS

#8 2014-03-04 02:10:26

Re: [Solved] Location of user config.h files in PKGBUILDS

Board footer