On 10/16/2014 05:10 PM, Jan Chaloupka wrote:
Have you considered installing the timer file, but without the dependency? If systemd is there, it could use it, otherwise not. That would make a whole lot more sense to me than creating another package, and would be my recommendation.
Nope, this is not going to work. If there's no dependency on systemd then during installation rpm can install man-db before systemd and and the timer will not get enabled. Currently it is not possible to install systemd units without a dependency on systemd.
Right which in turn will lead up to the scenario I tried to explain thousand times with FESCO that we would end up having components depend on systemd when they should not and with absolutely no benefit of and worse outcome as well as more frustrating aministrator/enduser experience than continuing to use cron for those jobs as well as obfuscating the work of those working on cleaning up the core/baseOS.
If it would have made sense to migrate every cron job to timer units I would have written and filed a feature proposal then and there which would achieve exactly that but the fact is that systemd timers and cronie are two component that complement each others short comings and systemd has quite few of those shortcomings compared to cron.
Unfortunately people only seem to see the outcome for their own component or their ( cloud ) product instead of thinking about the whole.
crontabs itself depends on systemd so what is the diffrence then?
That makes no sense crontabs serves as a virtual requires for cron daemon functionality
Those cron daemons can either be cronie, fcron, dcron,vixie-cron and or whatever else exist and is being shipped now and or in the future ( and now with products none should be the default, that should be left up to be specified by each product ) and those are the once that depend on systemd so either crontab depends directly on one of those daemons ( hardly ) or simply requires cron.d ( more likely ) which is provided by one of those cron daemons. ( I have not look at the spec so I dont know what the crontab did once my guideline changes finally got approved although they did not get approved in it's original form )
The difference is that you actually get correct dependencies on core/base installation but today alot of components don't mention ( or incorrectly ) mention dependencies on the core/base installation.
Now you might be scratching your head and think like those that got us into this mess to begin with " nah I dont need to worry too much about adding dependencies, this stuff is optional and the core/base installation will remain the same" wondering why is this so important?
The reason why it's so important is because nothing in this life is certain except for death and taxes and the components that make up the core/base installation are no exception in that regard.
Unlike most if not all features owners I take my work very seriously and I do not expect others to do my features for me ( there seems to be common practices for someone to come up with an idea which they label "feature" then tag all maintainers for affected components and tried to have them implement it for them, leaving the distribution with majority of it's feature half implemented since those maintainers either dont exist, dont care or dont have the time to do it ) and unlike other features owners I deal with components in the hundreds so I know more then most people how utterly broken the feature process in the distribution is.
One of my responsability as an feature owner is to gather the scope of the change I'm proposing so I can up to the best of my ability see how that change will affect the distribution and it was FESCo responsibility to validate that scope ( I would assume now that their role no longer exists or at least change significantly since there is no distributions default now with the products ).
I for the life of me could not property, reliable determine ( thus neither could FESCo ) the scope of my features because the dependency chain in the core/base installation is so utterly and completely broken. cron, logwatch, syslog, logging in general all utterly and totally broken. Seriously out of the entire what 600 components that ship daemons/services, 4 I think depended on rsyslog none on logwatch/logrotate 5 on cronie I think etc.
Now for the second half of my lengthy answer the benefical of migrating to timer units is only relevant to bootup,udev,unit startup,suspend,shutdown hence if your component does not already depend on systemd but ships cron job it should not be migrated period.
If people are so inclined and anxious to drop that cron job then they should spend their time and energy and write that rpm trigger(s) for man in accordance with what Peter Schiffer said as opposed to try to implement this with timer units and or workaround the FPG.
Which will led to a lot of dependencies on man-db because man-db's cache has to be updated.
Well as things are evolving and heading into arguably each man pages ( and documentation in general and yes I know it's tremendous amount of work ) will need to be package into it's own sub-package in a component ( which is what I proposed for the cron jobs as well so removal of crontab would remove them all but fpc decided to get *smart* and removed that from my proposal ) in the long run since people will want to keep their containers OS installs and vm's to absolute minimum regardless if they are hosts or the guest, granting administrators to install them on demand.
JBG