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

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

On 10/15/2014 05:36 PM, Ondrej Vasik wrote:
> On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote:
>>> On 10/15/2014 04:47 PM, Chris Adams wrote:
>>>> Once upon a time, Jan Chaloupka <jchaloup at redhat.com> said:
>>>>> there has been a discussion about if we need cache for man-db for users
>>>>> which use man pages or update system only from time to time and thus
>>>>> don't need to update cache every day. man-db as it is now depends on
>>>>> systemd which brings another set of packages. The use case is "I just
>>>>> want to read man page. So I install man which on the other hand download
>>>>> another set of packages. I want to read man page and it downloads systemd.".
>>>> On the majority of systems these days, is it really an issue to cache
>>>> man pages anymore?  I mean, back when a long man page (thinking about
>>>> some of the perl documentation for example) could take a while to
>>>> render, it mattered.  Now however, systems are much much faster, and we
>>>> expect GUI web browsers to render vastly more complicated content in a
>>>> fraction of a second.
>>>>
>>>> Maybe the time has come to just stop caching man pages at all, or at
>>>> least make that functionality optional (and non-default)?
>>>>
>>> Hello,
>>>
>>> I would add some noteworthy information:
>>>
>>>   * the man-db cron/timer script is taking care of man DB containing
>>> only the man page title and short description i.e., the first NAME
>>> section of the man page. This DB is speeding up the searching in
>>> mentioned section with the man -k command. It is not used for
>>> displaying man pages or doing the full text search with man -K command
>>> and it is not required for normal usage of man command (man -k should
>>> also work without this DB).
>>>
>>>   * Debian is updating this DB via deb hooks (or how it is called)
>>> during package installation/update and via daily cron script for man
>>> pages installed outside of package manager.
>>>
>>>   * updating this DB is usually pretty quick, but creation can take some
>>> time..
>>>
>>>   * man pages cache, pre-formatted man pages stored on disk in plain
>>> text, called cat pages in man-db context, is not used in Fedora.
>> I don't think that adding an additional subpackage to be manually
>> installed is worth the trouble. We should be making things simpler for
>> administrators, not require more manual involvement. From Peters'
>> description it seems it would be fine to simply ignore the timer and
>> not have the cache if systemd is not running for whatever reason. So
>> it would seem that ommitting systemd from the dependency list is the
>> answer. But omitting systemd from the dependency list is not possible,
>> because the dependency is necessary to order man-db after systemd in
>> case of a normal installation of both in one transaction. After things
>> calm down with F21, I'll return to the idea of splitting out
>> systemd-filesystem (name subject to change) to allow packages which
> Or we may even move unitdir into the basic filesystem package - if the
> unitdir is the only requirement - which is probably the case for most of
> the daemons. It would probably be better than systemd-filesystem
> subpackage.
>
> Ondrej

<mailto:pschiffe at redhat.com><sigh>

I discussed this with Peter Schiffer and the end result was in the 
future the man-db cron should be removed and man-db database should be 
updated with rpm triggerand the cron job should be kept as is until 
then, presicecly to prevent this from happening ( systemd being pulled 
in when it should not or component magically expecting it to be there )  
and correct dependency on coreOS/baseOS components would be kept.

Just make FESCO/FPC clean this up it was them who decided not to make it 
mandatory what should or should not be migrated to timer units and this 
is precisely the fallout I had expected from not doing that.

Those individuals need to start accepting responsibility for the fallout 
from their decision making so as I said have them clean it up.

JBG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141015/588bb5b1/attachment.html>