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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
