[csw-maintainers] Migrating config files from /opt/csw/etc to /etc/opt/csw during package update

[Maciej (Matchek) Blizinski]

I've crafted new cups and unixodbc packages, but I started to loath to
release them because of the migration from /opt/csw/etc to
/etc/opt/csw. In my case it was a non-issue: update Puppet
configuration definition, install packages, done. In a more general
case, somebody will just do an update and... bang. The new cups will
look for files in /etc/opt/csw/cups and won't find anything.

There was a brief discussion in Oslo about this. The ideas I've
collected so far:

1. Make the installation fail if the old config directory
(/opt/csw/etc/cups) or files exist.

Pros: It will make people (painfully) aware that there has been a
change and they need to take action. They will have an opportunity to
do the configuration move their way if they wish to.

Cons: It's annoying and potentially time consuming: the need to look
why the hell has the package failed, then go and devise a plan to move
the configs. If someone does a mass upgrade, there will be a mass
failure: CUPS will be uninstalled from everywhere and it won't be easy
to install it. (not from current, using CSW tools, that is)


2. Move the config files automatically. Identify all the configuration
files from the old /opt/csw/etc directory and move them to
/etc/opt/csw.

Pros: Smooth hands-off upgrade as expected (Quoting the website, our
motto, is "to provide a straightforward, easy-to-use experience for
the user").

Cons: Something in the scripts could go wrong, causing a mass failure.
(Probably not worse than in point 1, though.) There may be
difficulties with figuring out how to copy the common inter-zone
configuration from /opt to /etc. (CUPS didn't work in sparse
non-global zones anyway, but it might be an issue in a general case.)

Issues I see: how to deal with the non-global zones in the general case?

- How to fork the existing shared configuration into a per-zone /etc directory?
- How to identify which files to copy? A user might have created and
used more files than the package provided. (It could be detected in
some cases, but certainly not all.)


3. Create a classutils script to aid migrating the file. The package
author would provide a description on how to migrate the config files,
i.e. which old paths correspond to the new paths. The non-global zones
would have no source files, so they would get the default
configuration.

Pros: Our motto is...

Cons: non-global zones, if previously configured, would have their
configuration reset.


Thoughts?

Maciej