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

[Trygve Laugstøl]

rupert THURNER wrote:
> On Mon, Aug 24, 2009 at 11:10, Maciej (Matchek)
> Blizinski<maciej at opencsw.org> wrote:
>> 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?
> 
> our configuration has one writable directory, /opt/csw, and we
> appreciated a lot the isolated nature. putting the files in etc will
> render opencsw unusable for us.

Why do you have that requirement? Is it because of NFS deployments or 
zones? Lots of packages use /var already, how do you handle that?

--
Trygve