Re: Clarification of Policy and Packaging manuals requested
-----BEGIN PGP SIGNED MESSAGE-----
> > It has been proposed that that is not the case, that conffiles
> > are an independent classification.
> >
> > If that is the case, then under one interpretation (a) becomes
> > meaningless, since it only applies to the small subset of files that
> > are configuration files but are not conffiles (if indeed conffiles
> > are unconstrained).
Cutting this down to component parts, we have:
Configuration files:
- must reside in /etc (a) [undisputed]
- most are supposed to be conffiles [undisputed]
Conffiles:
- can only be used to describe configuration files [disputed]
- do not get munged during an upgrade [undisputed]
- specified as absolute pathname [undisputed]
Let's add a few more things:
- configuration files are not the only files that need to be
protected from upgrades
- the mechanism for handling protected files outside of the conffile
mechanism is non-intuitive at best.
If conffiles may be used to describe files other than
configuration files, the following occurs:
- It becomes difficult to separate configuration files from
"need-to-be-saved" data files inside of a .deb package.
- (Why do we need to do this?)
- It becomes easy to handle any file that you don't want
clobbered by an upgrade.
- The following have to be applied to conffiles:
- Are not inherently constrained to a given location
- Files listed as conffiles are still constrained by any other
rules that may apply to them; e.g. configuration files that
are conffiles must still go in /etc, variable data files
still go in /var, and so forth.
Taking that last section to be the case, I have difficulty seeing
how Manoj's objection that this somehow unconstrains configuration
files is actually the case.
I think that part of the problem here is that the term "conffiles"
inherently brings up the connotation of "configuration file", and
perhaps in fact it should. However, if one wishes to keep conffiles
specifically for configuration files, then some /simple/ mechanism
should be devised such that other files that need to be similarly
protected, can be.
After having lurked in debian-devel for a while, I suspect that
Manoj will object that developers for Debian need to be sufficiently
proficient in writing shell scripts and whatever else that they can
deal with this on their own. I think that mindset is not in the best
interests of the Debian project. One of the (several) reasons why I
switched from Redhat to Debian was the ease in which I was able to set
up my own local .deb files to maintain my own system. This provides
an atmosphere in which a community at large *can* contribute to a
system. The easier it gets to do this *in a proper fashion*, the more
software will show up as being available under Debian, even if it's
only in the contrib/non-free areas. Note that I don't mean this to be
understood as my condoning poor coding practice overall; for instance
a note was made on debian-devel of a case where someone had tagged a
shell script in /usr that got customized as a conffile, where in fact
it should have been including a configuration file from /etc, and I
agree that this ought to be filed as a bug.
This having been said, I propose the following solution:
Modify dpkg such that it will also recognize DEBIAN/noclobber (or
some such variant) and feed it exactly the same code as conffiles in
terms of protections. Add the following clarifications to the policy
and packaging manuals:
- conffiles are to be only used to handle configuration files
placed in /etc, not protected data files.
- noclobber files are used to protect non-configuration data that
should be preserved between upgrades. They should not be used
to protect files in /usr, as /usr should be mountable
read-only.
This leaves it up to the developer/maintainer whether s/he wants
to noclobber a given file, or whether that file should be handled by
other scriptable means (postinst/touch, post-purge delete, whatever).
=============================================================================
Zed Pobre <zcp@po.cwru.edu> | PGP key on servers, fingerprint on finger
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 5.0
Charset: noconv
iQEVAwUBNPIJOtwPDK/EqFJbAQFvRAf/SdbNbL1Ynm/QDXA620CrfGSgGkCr0EUd
/PZvhdwQAvc+shpA0jEVl2JnuZ2gctX7pYRU9CzPLy3hV7bRqDRCARRomgTClMLH
IWQ3u2pnmenb0rz/wT5sCBWsDV6vH15+999Og8u78vmxKEftTDl7vDQ1azG/U2Lr
zCQ3Etp9sNf4Jjff49zRRihhXxrj0x1qyFn/ZZ5efnSznDRWx77Sh/Fyc9lU3xyu
MHSMnFW+4sFFFCh4eWtyEkSul7e9Ul/CvnsaflHfqDHXdrKtVqXOY5LnLz9P7vMq
vScfTjLpq8wKza3Jxulf2n8HevU7kqUSLCvz39gSjCOvv9GwryIWmg==
=OJQd
-----END PGP SIGNATURE-----
Reply to: