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

[Zbigniew Jędrzejewski-Szmek]

On Wed, Oct 15, 2014 at 07:36:49PM +0200, 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.
This is not about the unit dir, but about the %post scripts:
'systemctl enable', 'systemctl preset', etc.

(I don't think that the ownership of the directory is that important.
Packaging rules, and all that, I know, but the truth is that both the
location and format of systemd unit files is a stable upstream API,
and cannot realistically change without significant upheaval. So
I'd be totally fine with different packages co-owning the directory,
except that this doesn't really solve anything.)

Zbyszek