On Sun, 19 Feb 2012 20:31:50 +0000 (UTC) Alex Elsayed <[email protected]> wrote: > > I'm slightly confused by your directory layout here. Let's say > > that /var/foo is also protected. Would that live in /var/foo/.c-p > > or /etc/.c-p/var/foo? > > /var/foo/.c-p
Wrong answer! > > > However, in order to support configuration management properly, we > > > cannot have the user altering the original files in the course of > > > managing these updates. Therefore, when the user would perform an > > > action that could modify the original file, the original file is > > > instead copied to the 'old' directory and the action is performed > > > on the copy. > > > > That sounds like it's getting in the way of the user. Supporting > > complex things is good, but we shouldn't force it upon people who > > don't want to screw around with configuration management. > > Maybe an option then? The current method of running the action on all > updates involved in the conflict at once would lose information in the > case of the user wanting configuration management, but I see your > point. Perhaps eclectic could call into the configuration management > plugins to ask whether they are active, and only change its behavior > if one answers "yes"? I think we need to be careful here. Replacing some of the silliness we inherited with config-protect is a good idea. What we don't want to do is tie config-protect into any particular user policy, particularly if that system is complicated and involves configuration management. The default should be something simple; being able to support fancy stuff on top of that is something a good design should allow, not something it should enforce. Perhaps a better question to ask is something like "how would we design config protection if it didn't already exist?". From the package mangler side there's probably not much difference here between having a choice of two mechanisms, or having one mechanism that's heavily parameterised. -- Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
