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@xxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
