Hi all, so - first off - I do not think this is an aliBuild matter, but it’s worth discussing it in any case, so thanks for starting this discussion!
TL;DR: do not edit default configuration files, leave them alone and managed by the package manager, and use override configuration files stored elsewhere, outside the installation prefix possibly.
Just to give you some context:
- aliBuild installs every single package in its own prefix, at least for now
- RPM generation is not part of aliBuild; it’s an independent system that relies on information provided by aliBuild to generate the proper packages
As for RPMs, we have two types of them ATM:
- RPMs that install in separate prefixes (each one in a different prefix) - they are the so-called non-updateable RPMs and are the ones that allow several versions of the same package to be installed at the same time
- RPMs that install under a single prefix (the updateable RPMs), which is - in any case - not
/
In order not to complicate the matters, I would not add any special option that installs “exceptions” outside the given prefix. We are trying to keep a “convention over configuration” approach so keeping the concept simple as it is (isolated prefixes) is, in my opinion, the way to go, and it has proven to be successful (from aliBuild packages we can seamlessly create CVMFS ones, RPMs, DEBs, etc. with zero effort).
For what concerns my packages, if I am in need for a certain configuration I tend to create a list of priorities for configuration files. This is more or less what @deklein suggested. You won’t have a single configuration file, but you will have your program look in order for, say, the following:
/etc/config.json.default (installed by the RPM, do not modify it!)$PREFIX/etc/config.json.default~/.config.json/etc/config.json
where every configuration file loads the configuration variable, and the next overrides any doubly-defined value.
This is the approach followed by any decent package by now: as you know, modifying something like /etc/httpd/httpd.conf used to be a PITA in the past, as any new update created something like /etc/httpd/httpd.conf.rpmsave or similar things, and you had the duty to figure out what changed upstream and merge your configuration appropriately. Nowadays you have an “uneditable” file and overrides, where the latter are not managed by the package manager (you can either manage them manually or with tools like Ansible, WP8 has more insight on that.
The CVMFS package (if you’ve ever configured it) for instance has:
/etc/cvmfs/default.conf (the configuration you are not supposed to edit)/etc/cvmfs/default.local (you add it and it overrides)
plus other repository-specific overrides, loaded in cascade.
Hope this helps!
