man-db without cache update (no cron or systemd *.timer)
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Thu Oct 16 22:55:39 UTC 2014
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.
>>>> 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
>> Unfortunately people only seem to see the outcome for their own
>> component or their ( cloud ) product instead of thinking about the
> crontabs itself depends on systemd so what is the diffrence then?
That makes no sense crontabs serves as a virtual requires for cron
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
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
More information about the devel