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(a)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@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