man-db without cache update (no cron or systemd *.timer)

["Jóhann B. Guðmundsson"]

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