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 _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
