Re: Setup of default configuration files

[Christopher Faylor <cgf at redhat dot com>]

On Sun, Jan 05, 2003 at 05:36:17PM -0000, Max Bowsher wrote:
>John Morrison wrote:
>>Christopher and I had a little conversation at the beginning of
>>December.  It occured to me/us that a lot of cygwin packages have
>>postinstall scripts which just copy default versions of configuration
>>files into the correct location if they don't already exist.
>>
>>It was thought that this could be simplified into just one
>>postinstallation script.  Basically, the script would, when a new file
>>has been placed under a particular directory (/etc/defaults/) it would
>>be copied (/etc/defaults/ becomming the equivalent of /) if a file of
>>the same name didn't already exist.
>>
>>This has (I think) two advantages 1) not everyone has to maintain such
>>a post installation script and 2) there's no excuse not to make use of
>>it and config files wouldn't be deleted upon uninstall.
>
>I think that in-package postinstall scripts are better: mainly because
>incver_ifdep only causes the action to happen when a package is put on
>the mirrors, not when the package is installed.  Suppose:
>update-defaults is in Base, so I have it installed.  When it
>incver_ifdeps, it gets re-run.  Later, I decide to install another
>package.  Its config files don't get copied from /etc/defaults.

I raised this objection (in a more vague way) when John and I were first
discussing this idea.  However, consider that before I implemented the
regeneration of the "dir" file, there were constant complaints about it
being out of date and now there are none.  This may be because package
creators are very careful about regenerating the dir file now or it may
be because my package is working even though it is not perfect.

However, it is probably more crucial that /etc/defaults files are
installed than it is for a .info file to be regenerated so it can't be
an iffy thing.  So, with the current scheme the /etc/defaults installer
is guaranteed to be installed and there is nothing to stop a package
creator from calling the update scripts directly.

It's easy to envision an update to setup.ini which would add a
"install-trigger" to be run whenever a package is installed.  The
trigger could either be added specifically to setup.hint or it could be
autogenerated from upset.

>That's not to say I don't think /etc/defaults itself is a good idea.
>I'd rather see a situation where packages installed files to
>/etc/defaults, and there was a boilerplate postinstall script that
>packages could incorporate.

Such a postinstall would be part of this package.

>Actually, this method might be better for update-info-dir as well.

Ditto for update-info-dir.  Go ahead and use it if you want.

I'm getting a deja vu feeling here.  I keep advocating that we should
have the computer do as much as possible for us.  If it is as simple
as just putting something in /etc/defaults or just *having* a .info
file in the distribution then it is obviously a win.

I also advocate not redundantly setting curr or prev or labelling
packages with '@package' in setup.hint because the computer does a
peachy job of figuring this out automatically.  Same thing in my book.

>Since there is a boilerplate package building script now in CVS, it
>could even incorporate the postinstall scripts in here documents.
>Then, if we want to be really clever, the build script can list
>/usr/info and /etc/defaults within the binary package being prepared,
>and create the appropriate postinstalls.
>
>Comments?

I don't want to use a package generation script.  I've got a perfectly
fine one of my own and forcing me to use another one to accommodate
something that could be completely transparent doesn't make sense.  That
is basically asking 27 package maintainers to change the way they do
things rather than just changing setup.exe.

cgf