| 1 |
On Sun, Nov 5, 2017 at 4:40 PM, Ian Zimmerman <itz@××××××××××××.org> wrote: |
| 2 |
> On 2017-11-05 14:22, Rich Freeman wrote: |
| 3 |
> |
| 4 |
>> Second, my actual objection is more to sticking wrappers around an |
| 5 |
>> upstream program just to extend its capabilities, when other software |
| 6 |
>> is maintained upstream that already does what you're re-inventing. |
| 7 |
>> When you already have 47 different cron implementations out there, I'm |
| 8 |
>> not sure it adds a lot to have a distro-specific solution. The distro |
| 9 |
>> should certainly be providing stuff like /etc/cron.*/ and the scripts |
| 10 |
>> inside when upstream isn't providing them. By all means include a |
| 11 |
>> stock wrapper /etc/crontab that runs that stuff at set times for those |
| 12 |
>> running 24x7 with vixie cron. If run-scripts was implemented in |
| 13 |
>> python instead of shell this objection wouldn't go away. |
| 14 |
> |
| 15 |
> I really want to stop prologing the agony of this thread, but I just |
| 16 |
> have to point out that when you install cronie with the anacron flag (as |
| 17 |
> I just did, if only to know what I'm talking about), you _still_ get a |
| 18 |
> wrapper: it's called /etc/cron.hourly/0anacron. Simpler than run-crons |
| 19 |
> for sure, but the principle is the same. |
| 20 |
|
| 21 |
Sure, but that is upstream-maintained, and that is my point. It comes |
| 22 |
out of the upstream contrib directory: |
| 23 |
https://github.com/cronie-crond/cronie/blob/master/contrib/0anacron |
| 24 |
|
| 25 |
> After all distros exist for a reason (over and above building packages). |
| 26 |
> If upstreams always did the glue job right, a bot could handle all the |
| 27 |
> package builds and you gentoo devs could go home ;-) |
| 28 |
|
| 29 |
In your example upstream DID do the glue job right. Even so, the glue |
| 30 |
isn't the part I object to. Running cron jobs after a system comes |
| 31 |
back online isn't glue - that is core functionality, even if not every |
| 32 |
implementation has it. |
| 33 |
|
| 34 |
Distros will always have to do integration work, and that is fine. |
| 35 |
That is the role of a distro. And sometimes distros have to roll |
| 36 |
their own tools when they just aren't available. Once upon a time |
| 37 |
service managers fell into that category. Now this is less the case. |
| 38 |
|
| 39 |
There is of course nothing wrong if people want to implement things. |
| 40 |
I just tend to prefer to stick with stuff that has an upstream that is |
| 41 |
bigger than one distro. |
| 42 |
|
| 43 |
-- |
| 44 |
Rich |
Archives