[Freedombox-discuss] Chef and Puppet experts?

[Philip Hands]

On Wed, 14 Sep 2011 11:07:49 -0700, FreedomBox-Discuss.NeoPhyte_Rep at OrdinaryAmerican.net 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20110915/9f6e6aee/attachment-0001.pgp>