On Mon, Aug 24, 2009 at 11:10, Maciej (Matchek) Blizinski<[email protected]> 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. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers
