On Wed, 14 Sep 2011 11:07:49 -0700, [email protected] wrote: ... > > Using any of Puppet/Chef/cfengine to achieve the same effect is > > effectively just an attempt to side-step the edict against one package > > modifying the conffiles of another (which would be another way of doing > > this) -- while that edict is sometimes inconvenient, it's there for good > > reason so one should be very cautious before ignoring it. > > I'm sorry, but I'm new around here. ("here" being the Debian project.) > Can you point us to that edict?
[note: not all configuration files are tagged as conffiles -- conffiles are a special case where the package manager has been told that it's in charge of ensuring that the files not be damaged during upgrades: http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files ] Section 3, paragraph 3, of this: http://release.debian.org/squeeze/rc_policy.txt Packages must not modify other packages' configuration files except by an agreed upon APIs (eg, a /usr/sbin/update-foo command). rc_policy.txt is the list of things that would have justified a release critical bug in the latest stable release -- I failed to find it in the general policy docs, but note that the same thing is also mentioned here: http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt * updated section about `Configuration files': packages may not touch other packages' configuration files in 1997. Perhaps it's so fundamental that it doesn't need to be written down in policy -- I suppose it's just a special case of the fact that packages shouldn't tread on other package's files. > I'm eager to learn the Debian way, but it's quite difficult to find > where to start studying what some folks seem to believe is common > knowledge. Yes, I was a little surprised to find out that that wasn't spelled out explicitly in the policy (unless I'm just being a bit dim). > I can understand it might have something to do with security and how > best to implement reliable code. Am I on the right track? It's more to do with the reliability -- it's very difficult for the user to work out why they ended up in a particular state if you have one package editing another's conffiles, since the final state is likely to depend upon the order that packages were installed/removed. The resulting confusion is bad for the user, and thus bad for our bug tracking system. Of course, this is only for packages in Debian itself -- people often achieve the same effect as having puppet or whatever by having a site-local repository of packages that depend on loads of packages and have postinst scripts that tweak all sorts of stuff, flouting policy completely -- that's fine, but those packages are not something that would get uploaded to Debian. People have even made packages to make building such packages easier: http://debathena.mit.edu/config-packages/ This might be of interest too: http://wiki.debian.org/ConfigPackages Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
pgpStjwtANSgn.pgp
Description: PGP signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
