dcron 4.2
 

On 01/06/2010 01:09 AM, Paul Mattal wrote:

Proposal: We stay with dcron into the 4.0 series, with a
longer-than-usual testing window so the transition is smooth, and see if
it meets our collective needs. Jim may be willing to add functionality
we find lacking.

Please get your votes and comments in by the weekend, if possible. I'd
like to move on this next week, if we have agreement.


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].


I'd like to get 2 signoffs for each architecture for this one, since it
represents a lot of new functionality. Full changelist since 3.2 inlined
below. For further info, and a full git history, see:


http://www.jimpryor.net/linux/dcron

- P

***

For more information,

v4.2 11-Jan-2010

* Makefile tweaks; moved more constants to #defines.

v4.1 10-Jan-2010
* Fixed bug in parsing some numeric fields in crontabs. (Terminus of
range

wasn't being modded.)

* Updated Makefile to make it easier to customize timestamps at configure
time. Also, if LC_TIME is defined when crond runs, we use that
instead of
compiled-in default (for logging to files, to customize syslog
output use

syslog-ng's 'template' command).

* Fixed Makefile permissions on crond and crontab binaries.

v4.0 6-Jan-2010
* Jim Pryor took over development; folded in changes from his fork
"yacron"


* Applied "Daniel's patch" from dcron 3.x tarballs to enable logging
to syslog or

files. Added further logging improvements.

* Added -m user@host and -M mailer options

* Various crontab syntax extensions, including "2nd Monday of every
month",

@reboot, @daily, and finer-grained frequency specifiers.

* Jobs can wait until AFTER other jobs have finished.

* Enhanced parsing of cron.update file, to make it possible for
scripts to

interact with a running crond in limited ways.

* Various internal changes

* Updated Makefile, manpage buildchain, and docs

dcron 4.2
 

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:
>>
>> Proposal: We stay with dcron into the 4.0 series, with a
>> longer-than-usual testing window so the transition is smooth, and see if
>> it meets our collective needs. Jim may be willing to add functionality
>> we find lacking.
>>
>> Please get your votes and comments in by the weekend, if possible. I'd
>> like to move on this next week, if we have agreement.
>
> 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].
>
> I'd like to get 2 signoffs for each architecture for this one, since it
> represents a lot of new functionality. Full changelist since 3.2 inlined
> below. For further info, and a full git history, see:
>
> http://www.jimpryor.net/linux/dcron
>
> - P
>
> ***

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.

Eric

dcron 4.2
 

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

dcron 4.2
 

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

dcron 4.2
 

On Mon, Jan 11, 2010 at 13:38, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> 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
>

+1

dcron 4.2
 

[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

dcron 4.2
 

On Mon 11 Jan 2010 13:54 -0500, Daenyth Blank wrote:
> On Mon, Jan 11, 2010 at 13:38, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> > 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
>
> +1

I appreciate that you've added to the discussion.
I hope that we may reach a large sum total.
+100

Cheers!

dcron 4.2
 

Am 11.01.2010 19:38, schrieb Aaron Griffin:
> 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

I would even go further and recommend not to modify the daemon script,
but rather create a copy on the filesystem (not tracked by pacman) and
use/modify that one.

dcron 4.2
 

On Mon, Jan 11, 2010 at 4:38 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 11.01.2010 19:38, schrieb Aaron Griffin:
>> 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
>
> I would even go further and recommend not to modify the daemon script,
> but rather create a copy on the filesystem (not tracked by pacman) and
> use/modify that one.

We're also going to get a ton of bug reports here if the init script
changed- a lot of people will not move the new one in to place, which
will never replace the old one because it wasn't tracked before by
backup and pacman won't overwrite it automatically.

I'd agree with Thomas here- there are multiple ways to avoid getting
your local changes overwritten. It might be in /etc/, but this is all
but a binary that we (as a distro) happen to maintain, so people
should not be regularly changing these scripts.

-Dan

dcron 4.2
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

I'm fairly new to the Arch Linux scene so am still learning a lot
about package building and maintenance. Left over from my Slackware
days gone by, Iknow well the importance of the rc.d scripts and how
they work. For local stuff, there's rc.local and hopefully a package
upgrade doesn't clobber that one because one would expect local users
to modify that one. However, I can see the point in ensuring the
other scripts aren't locally modified without realizing that a package
future upgrade will overlay it. If this isn't done already, maybe the
alternative configuation methods should be well documented in the wiki
or some place detailing the use of /etc/conf.d.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAktL+U0ACgkQWSjv55S0LfHckwCgrAqtTOQ51V OMRJavh2rbh5ck
R1YAoKQ1MomlcLQZvvt06momMKSUZkcU
=WwLU
-----END PGP SIGNATURE-----