Here the not so pretty proposal I promised at the meeting ;)

https://fedoraproject.org/wiki/User:Johannbg/Packaging/CronFiles

Thanks for your draft, we reworked it a bit and approved this revision:

https://fedoraproject.org/wiki/User:Spot/Packaging/CronFiles

(+1:5, 0:0, -1:0)

Ah interesting I just quickly threw that proposal together and had forgot the usage of /etc/cron.d directory is not on par with the cron.monthly/, cron.daily/,cron.hourly/ and cron.weekly/ directories as in you drop a file with the scheduled interval into the /etc/cron.d directory and the actual script into (s)bin directory opposed to the script into /etc/cron.d directory and create the scheduled interval entry in /etc/crontab which just show how rarely I bother scheduling cron jobs .

We might want to quickly glans over [1] encase we missed something and or want to add something more anyway I'll start working on patching the relevant spec files for the packages shipping cron job now with the approved guideline changes.

Thanks for approving this

1.http://refspecs.linux-foundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/sysinit.html#CRONJOBS

I assume we want this in the guidelines as well ( different file permission for cron.d snippets since they are not scripts )

%{__install} -p -D -m 0640 %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/cron.d/%{name}

[https://fedoraproject.org/wiki/Packaging:CronFiles?rd=Packaging/CronFiles#Cron_job_file_names There] is a small typo:

the file names should all start with the name of the package by a hyphen

A ''followed'' word is missing between ''package'' and ''by''.

Thanks. Fixed.

The current [https://fedoraproject.org/wiki/Packaging:CronFiles guideline] says that all cron job files should be marked as %config(noreplace), even those in cron.{hourly,daily,weekly,monthly}.

At least in some cases this doesn't make sense, especially when that "cron job file" in question is really a script, not a configuration item. A common pattern for those scripts is to source some (real) configuration file, and conditionally act depending on the configuration, like this:

{{{

!sh

if [ -r /etc/foo.conf ] ; then
. /etc/foo.conf
if [ "$FOO_CRON_ENABLED" == "1" ] ; then
# ...
fi
fi
}}}

There's not much for the user to edit here. In my opinion such a script is a script, not a configuration file, and I don't see why it should be marked %config.

Can this be revisited?

I just wrote a use case in a reply to #324 that applies to this:

In actual use in Fedora Infrastructure, this practice [wrapper scripts similar to what you mention] would be of use as we sometimes modify cron jobs to do things like:

* Create a lock so that we don't have two instances of the cron job running at the same time.
* If the cron job errors, only send that error once per day instead of at every invocation.

Would that be sufficient justification to you or should we still revisit this? (I'm open either way, as noted in #324, I'm not certain that this was a use that we purposefully set off to enable so I don't know if it's something we want to protect now.)

Replying to [comment:9 toshio]:

I just wrote a use case in a reply to #324 that applies to this:

In actual use in Fedora Infrastructure, this practice [wrapper scripts similar to what you mention] would be of use as we sometimes modify cron jobs to do things like:

* Create a lock so that we don't have two instances of the cron job running at the same time.
* If the cron job errors, only send that error once per day instead of at every invocation.

Would that be sufficient justification to you or should we still revisit this? (I'm open either way, as noted in #324, I'm not certain that this was a use that we purposefully set off to enable so I don't know if it's something we want to protect now.)

Imho this is not sufficient justification, for these reasons:

• [locking] If locking is needed, that would be a bug in the script which should be fixed upstream. If you have to fix the cron script to add locking, that would not be a configuration change.

• [notification frequency] Hm, this could be a reason, albeit a bit constructed/weak. How often does it happen that you want a cron job to be executed every hour, but only notified about failures after a maximum of 24 hours? You are then ''implementing'' (by writing code, how short it may be) a functionality that would be nice to have in cron itself. Stretches the word 'configuration' a bit.

But there's a counter argument: If there's (before you modify it) really code in the cron script, you would miss upstream changes of this code, when the file is marked %config(noreplace). Why would that be ok for a script that happens to be in /etc in contrast to a script that lives in /usr/bin?

The reason why we are discussing this is that the boundary between code and config is not always clear, and people would draw the line differently, e.g. depending on their programming skills. Is (emacs) lisp configuration or code?

As an example, take /etc/cron.daily/rkhunter. Code or configuration? I'd vote for code, although in the end, these 57 lines boil down to one call to the rkhunter binary.

N.B. #324 is different. As far as I understand, ppisar thinks the current guideline could be interpreted in a way that (helper) scripts in %{libexec} also have to be marked as %config files, when called by (wrapper) cron scripts.

We discussed this at today's meeting and decided that the guideline is as intended.

Proposed comment for ticket: FPC intends the cron job files in %{_sysconfdir}/cron* continue to be %config(noreplace) if the packager feels strongly about the code portion needing to update they should move the file to a helper location (%{_libexeecdir} for instance) and write a wrapper for the actual cron job file.

(+1:6, 0:0, -1:0)