[I'm reposting this to arch-dev-public on Jim's behalf. -P] I agree our general convention is not to put /etc/rc.d scripts in our backups arrays, but it seems that doing so has no effect if you don't modify them and has a potentially-work-saving effect in case you do and forget. If others feel strongly, I'll remove it from backup, but don't see much harm in having it there. - P On Mon, Jan 11, 2010 at 11:36:55AM -0500, Eric Bélanger wrote:

On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal <paul@mattal.com> wrote:

...

On 01/06/2010 01:09 AM, Paul Mattal wrote: I've just placed dcron 4.2 into [testing]. This is a major update to dcron, under a new maintainer (who is an Arch user, and very responsive). With this release, I am also taking over maintaining dcron in [core].

Why did you put etc/rc.d/crond in the backup array? These daemon scripts are not intended to be modified by the user. If you want them to be able to pass different options, you should use a /etc/conf.d/crond config file.

Hi Eric, I did that in a proposed PKGBUILD I sent to Paul. It'll be up to him how to package this, but this prompts a more general question I have. Granted that daemon scripts are not supposed to be modified by the ordinary user; the /etc/conf.d mechanism is the usual way to supply arguments to the daemon scripts. However, it's one thing to say "not usually supposed to be user-modified" and slightly different to say "overwrites user mods without notice." I find myself tweaking a few /etc/rc.d scripts now and then. I know there's an existing mechanism to protect such changes: NoUpgrade in /etc/pacman.conf. But I wondered why more PKGBUILDs didn't just add the daemons to the backup array. So the question is: should we think of it as _policy_ that rc.d scripts don't go in backup array, and should instead always be explicitly protected by the user if user wants to mod? No problem if so, it's actually helpful to know there's an explicit policy to always do it the one way or always do it the other way. As to dcron 4.2, I've already gotten some feedback. Thanks. I'll release a new version shortly, but do keep feedback coming. -- Jim Pryor profjim@jimpryor.net