Forwarding Colin's response =================================
On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote:
Once upon a time, Jan Chaloupka jchaloup@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.".
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.
On the majority of systems these days, is it really an issue to cache man pages anymore?
That's not what the timer unit in question is for! It updates the database of which manual pages are present and their descriptions, not rendered pages. You need it for apropos and whatis to work.
(I would also recommend arranging to update the database any time packages that ship manual pages are installed or removed, but I don't know whether this is a straightforward thing to do with your package management infrastructure. In Debian we do this with dpkg triggers.)
Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)?
It's been optional for many years, is I believe generally off in Fedora given that you don't install mandb set-id, and is unrelated to this issue.
Cheers,
Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a):
Forwarding Colin's response
On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote:
Once upon a time, Jan Chaloupka jchaloup@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.".
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.
Actually that is good idea IMO. The %post script could silently fail if no systemd is no the system.
On the majority of systems these days, is it really an issue to cache man pages anymore?
That's not what the timer unit in question is for! It updates the database of which manual pages are present and their descriptions, not rendered pages. You need it for apropos and whatis to work.
(I would also recommend arranging to update the database any time packages that ship manual pages are installed or removed, but I don't know whether this is a straightforward thing to do with your package management infrastructure. In Debian we do this with dpkg triggers.)
%triggerin and %triggerun probably can't achieve this, but RPM plugin could do that.
Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)?
It's been optional for many years, is I believe generally off in Fedora given that you don't install mandb set-id, and is unrelated to this issue.
Cheers,
On 10/16/2014 12:56 PM, Vít Ondruch wrote:
Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a):
Forwarding Colin's response
On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote:
Once upon a time, Jan Chaloupka jchaloup@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.".
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.
This did not crossed my mind.
Actually that is good idea IMO. The %post script could silently fail if no systemd is no the system.
Agree with Vita, this sound very good to me. Made a test build and it is working fine. Now the installation is much more smaller:
================================================ Package Arch Version Repository Size ================================================ Installing: man-db x86_64 2.6.7.1-10.fc21 /man-db-2.6.7.1-10.fc21.x86_64 1.7 M Installing for dependencies: less x86_64 458-13.fc21 fedora 125 k libpipeline x86_64 1.3.0-4.fc21 fedora 49 k
Transaction Summary ================================================ Install 1 Package (+2 Dependent packages)
Total size: 1.9 M Installed size: 2.0 M
Installed: man-db.x86_64 0:2.6.7.1-10.fc21
Dependency Installed: less.x86_64 0:458-13.fc21 libpipeline.x86_64 0:1.3.0-4.fc21
On the majority of systems these days, is it really an issue to cache man pages anymore?
That's not what the timer unit in question is for! It updates the database of which manual pages are present and their descriptions, not rendered pages. You need it for apropos and whatis to work.
(I would also recommend arranging to update the database any time packages that ship manual pages are installed or removed, but I don't know whether this is a straightforward thing to do with your package management infrastructure. In Debian we do this with dpkg triggers.)
%triggerin and %triggerun probably can't achieve this, but RPM plugin could do that.
Maybe the time has come to just stop caching man pages at all, or at least make that functionality optional (and non-default)?
It's been optional for many years, is I believe generally off in Fedora given that you don't install mandb set-id, and is unrelated to this issue.
Cheers,
On Thu, 2014-10-16 at 13:34 +0200, Jan Chaloupka wrote:
On 10/16/2014 12:56 PM, Vít Ondruch wrote:
Dne 16.10.2014 v 10:35 Jan Chaloupka napsal(a):
Forwarding Colin's response
[... snip ...]
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.
This did not crossed my mind.
Actually that is good idea IMO. The %post script could silently fail if no systemd is no the system.
Agree with Vita, this sound very good to me. Made a test build and it is working fine.
But it's contrary to the guidelines, as you're installing the unit file in %{_unitdir}, without requiring systemd to own this directory.
Which goes back to the idea of either moving %{_unitdir} to the filesystem package, or having a systemd-filesystem package...
On Thu, Oct 16, 2014 at 01:54:41PM +0200, Mathieu Bridon wrote:
Which goes back to the idea of either moving %{_unitdir} to the filesystem package, or having a systemd-filesystem package...
https://bugzilla.redhat.com/show_bug.cgi?id=1153638
Dne 16.10.2014 v 14:09 Matthew Miller napsal(a):
On Thu, Oct 16, 2014 at 01:54:41PM +0200, Mathieu Bridon wrote:
Which goes back to the idea of either moving %{_unitdir} to the filesystem package, or having a systemd-filesystem package...
I can't see nothing against guidelines [1]. They says that you *can* depend on systemd package. If man-db owns the directory, then it should be perfectly fine (althoug you might be referring to "systemd unit files must put them into %{_unitdir}", but I deliberately interpret is as expanded path).
Of course this should be revisited when Zbigniew will find a time or the ticket below is resolved.
Thanks Matthew.
Vít
[1] https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations
On Thu, Oct 16, 2014 at 10:35:13AM +0200, Jan Chaloupka wrote:
Forwarding Colin's response
On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote:
Once upon a time, Jan Chaloupka jchaloup@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.".
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.
Zbyszek
On 10/16/2014 01:30 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Oct 16, 2014 at 10:35:13AM +0200, Jan Chaloupka wrote:
Forwarding Colin's response
On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote:
Once upon a time, Jan Chaloupka jchaloup@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.".
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.
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.
JBG
On 10/16/2014 04:49 PM, "Jóhann B. Guðmundsson" wrote:
On 10/16/2014 01:30 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Oct 16, 2014 at 10:35:13AM +0200, Jan Chaloupka wrote:
Forwarding Colin's response
On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote:
Once upon a time, Jan Chaloupka jchaloup@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.".
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? mock -r fedora-21-x86_64 --init ... mock -r fedora-21-x86_64 --install crontabs ... Installed: crontabs.noarch 0:1.11-9.20130830git.fc21
Dependency Installed: acl.x86_64 0:2.2.52-7.fc21 cronie.x86_64 0:1.4.12-1.fc21 cronie-anacron.x86_64 0:1.4.12-1.fc21 cryptsetup-libs.x86_64 0:1.6.6-1.fc21 dbus.x86_64 1:1.8.6-3.fc21 dbus-libs.x86_64 1:1.8.6-3.fc21 device-mapper.x86_64 0:1.02.90-1.fc21 device-mapper-libs.x86_64 0:1.02.90-1.fc21 fipscheck.x86_64 0:1.4.1-7.fc21 fipscheck-lib.x86_64 0:1.4.1-7.fc21 kmod.x86_64 0:18-3.fc21 kmod-libs.x86_64 0:18-3.fc21 libseccomp.x86_64 0:2.1.1-5.fc21 qrencode-libs.x86_64 0:3.4.2-4.fc21 systemd.x86_64 0:215-19.fc21
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.
JBG
Regards Jan
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
-
Jan Chaloupka -
Jóhann B. Guðmundsson -
Mathieu Bridon -
Matthew Miller -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek