[arch-general] [arch-dev-public] [signoff] dcron 4.2

[Jim Pryor]

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 at 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 at jimpryor.net