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

rupert THURNER rupert at opencsw.org
Sat Aug 29 08:43:41 CEST 2009


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.

rupert.



More information about the maintainers mailing list