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

[Aaron Griffin]

On Mon, Jan 11, 2010 at 12:16 PM, Jim Pryor
<lists+arch-general at jimpryor.net> wrote:
> 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?

If you modify it, you should add it to the NoUpgrade line in
/etc/pacman.conf. The backup array is for what we INTEND to be
modified. Users are more than welcome to do what we don't intend, but
you need to control whether of not pacman mucks with those files
yourself