proposal for ghc-pkg to use a directory of .conf files

Hi, It has been common in recent years since the widespread use of package management systems to break up configuration / settings files that are used by several packages into a directory of individual files rather than modifying a global file. The advantage of doing this is that it makes things easier for the package managers. Each individual file can belong to the appropriate package and so instead of having to execute registration/unregistration actions on install/uninstall it's just another file to add/remove. The other advantage is that there is no longer a global file that needs to be modified which means uninstallation is cleaner (most package managers do not remove files that were modified after installation). So the idea is that in addition to a single $HC-LIB/package.conf file you have a directory of package files $HC-LIB/package.conf.d/*.conf Obviously, the package chasing code needs to be tweaked slightly to slurp in a whole directory of .conf files and $HC-pkg would want to be able to use a directory as an installed package source. I had a peak at the code in ghc for dealing with .conf files. I'd guess it'd be best ok just check if the specified package file is a directory or an ordinary file and act accordingly. Ie you could say "-package-conf packages/" and ghc could by default read from $HC-LIB/package.conf and $HC-LIB/package.conf.d/ or something. I can knock up a proof of concept patch if anyone thinks this is a good idea. It should be totally backward compatible, it's ok to use both, but ditro packagers might like to enforce a policy of using a directory of package files for external libraries. Duncan

Duncan Coutts wrote:
[...] The advantage of doing this is that it makes things easier for the package managers. Each individual file can belong to the appropriate package and so instead of having to execute registration/unregistration actions on install/uninstall it's just another file to add/remove. The other advantage is that there is no longer a global file that needs to be modified which means uninstallation is cleaner (most package managers do not remove files that were modified after installation).
These are exactly the reasons why e.g. the configuration files for apache2 on my SuSE Linux 9.1 are set up this way. It's very handy, clean and modular.
[...] I had a peak at the code in ghc for dealing with .conf files. I'd guess it'd be best ok just check if the specified package file is a directory or an ordinary file and act accordingly. Ie you could say "-package-conf packages/" and ghc could by default read from $HC-LIB/package.conf and $HC-LIB/package.conf.d/ or something.
Sounds resaonable to me. I can't see any downsides of doing it this way.
I can knock up a proof of concept patch if anyone thinks this is a good idea. It should be totally backward compatible, it's ok to use both, but ditro packagers might like to enforce a policy of using a directory of package files for external libraries.
OK, just send us a patch and if there are no objections we can merge it into the HEAD. Cheers, S.
participants (2)
-
Duncan Coutts
-
Sven Panne