Re: man-db without cache update (no cron or systemd *.timer)
On Mon, Oct 20, 2014 at 3:24 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 20.10.14 15:08, Matthew Miller (mat...@fedoraproject.org) wrote: On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote: But again, I am not sure I understand what is going on here. Is systemd now optional in Fedora? I guess to some degree everything is optional in one way or another. It's certainly the init system we are using. I think the context is in cases where the packages are used without an init system, systemd or otherwise — the main case being single-process (or at least single-parent-process) application containers. (I'm also looking forward to systemd as a process manager inside e.g. Docker for more sophisticated multi-process applications which for whatever reason want to be in the same container, but that's a different use case.) While I can see the reason why you want this I really find this quite dubious in general. Much of our stack relies on /run and all those other facilities, of our general execution environment to be properly initialized, cleaned up and maintained. We do this with tmpfiles snippets, early-boot services, cron jobs, timer units, and so on and so on. Just saying no to these things, ignoring them and not executing them will only get you so far. It also creates in a way a new execution environment, unless you perfectly replicate the execution environment from your container manager, knowing all components in play, including all libraries and whatever else. A container is _absolutely_ a new execution environment, and the whole advantage of it, to most users, is that it's more lightweight than a complete virtualized OS environment, partly because you do not have to load an entire operating system. There is enough abstraction to make running a distinct set of packages (even a different distro/version) reasonable, but with the luxury of not having to deal with network setup, filesystem checks and mounts, initialization of cgroups, and all those other fun things, because a combination of systemd, docker, and other host services have done all the work. And things like logging the output of the service, restarting it if it crashes, etc. can easily be taken care of by making a systemd unit for the container in the *host* OS. I'm not sure what to make of your comment about knowing all component in play, including all libraries and whatever else, because that seems to indicate that you are worried about dependency closure inside the container, which is the responsibility of whomever built the container. Assuming they did so in a sane way with a package management system, they will be fine from that standpoint. If you really intend to make Fedora in general workable without providing support for tmpfiles bits, without cron jobs, without timer units, without setting up the execution environmnt the same way as on a classic Fedora boot, then please make this a clear goal of Fedora. But just trying to add this through the backdoor sounds wrong. First, I would say that the community has rammed this requirement right through the front door. People _are_ running things this way. This is not some theoretical future feature; it's an adaptation to existing use cases. Second, things like tmpfile cleanup and log rotation are not requirements for a service to function. This is why, for example, none of the many packages which put file in /etc/logrotate.d/ actually require logrotate. Sure, it's nice if it's there, but a user is also free to come up with their own procedure for rotating logs, or to not rotate them at all. I would be interested to know some other concrete examples of concerns about the execution environment that would actually impact the functionality of a service in a container. I won't claim that such things don't exist, but tmpfile clean-up and log rotation are poor examples, IMHO. Honestly though, I really don't think this is really such a good idea. You make things much more complicated for developers that way. We *want* developers to make use of the OS services we provide after all. It makes the system more uniform and more accessible to our admins and users. If you take the vast majority of the facilities that we provide for software away, then very little remains, you devalue the OS itself. We are not taking these things away. Matt even mentioned that he would like to see us provide containers with systemd inside them as an option, but it will necessarily be a more heavyweight option than the current use case which has become so common, and it will be uninteresting to many users. The value in these OS services of which you speak are significant in the host OS, which has to manage the orchestration of many containers in this new world. For the developer (who is *not* a sysadmin) the value of these services is quite minimal. They want to build an app, and run the app, and to have as little concern as possible for the
Re: man-db without cache update (no cron or systemd *.timer)
On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote:
Hmm, not sure I follow here. Since when is systemd an optional
component in Fedora?
I have been spending much of my time building Fedora-based Docker
containers recently. I've been sticking to the
one-process-per-container model because I think it brings a number of
advantages. One of the biggest, in my opinion, is that container
management reduces to process management, and I already have a
great process manager on my host. It's called systemd.
Decomposing an application into single-process containers also means
that it's easier to scale individual components. *And* for many
applications -- those that can log to stderr/stdout -- it means
that application logs show up in my host journal *where I want them*.
Running any sort of process manager inside the container can also have
the unintended side-effect of hiding problems from the host. If an
application is failing to start because of a configuration issue, I
don't want that managed inside the container -- I want the host to be
aware of that so that higher-level mechanisms can be involved. I want
a host- or cluster- level container manager to be able to restart
dependent containers, or to have the opportunity to reschedule a
container on another host.
I think it is absolutely essential that systemd is *able* to run
inside a container -- because I think there are invariably going to be
situations in which the one-process-per-container model simply doesn't
pan out. But I also think that in many situations it is not required
and using systemd inside the container simply complicates things.
--
Lars Kellogg-Stedman l...@redhat.com | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
pgpM0qJf6tF8K.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On Wed, 15.10.14 16:10, Jan Chaloupka (jchal...@redhat.com) wrote: Hi, 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.. Hmm, not sure I follow here. Since when is systemd an optional component in Fedora? There appear to be two reasons to depend on the systemd package: for correct ownership of the unit directory, and for being able to invoke systemctl. The former could be fixed by moving the ownership to filesystem.rpm. The shouldn't realy matter as the command should be suffixed by /dev/null 21 || : anyway... But again, I am not sure I understand what is going on here. Is systemd now optional in Fedora? Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote: But again, I am not sure I understand what is going on here. Is systemd now optional in Fedora? I guess to some degree everything is optional in one way or another. It's certainly the init system we are using. I think the context is in cases where the packages are used without an init system, systemd or otherwise — the main case being single-process (or at least single-parent-process) application containers. (I'm also looking forward to systemd as a process manager inside e.g. Docker for more sophisticated multi-process applications which for whatever reason want to be in the same container, but that's a different use case.) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On Mon, 20.10.14 15:08, Matthew Miller (mat...@fedoraproject.org) wrote: On Mon, Oct 20, 2014 at 08:56:19PM +0200, Lennart Poettering wrote: But again, I am not sure I understand what is going on here. Is systemd now optional in Fedora? I guess to some degree everything is optional in one way or another. It's certainly the init system we are using. I think the context is in cases where the packages are used without an init system, systemd or otherwise — the main case being single-process (or at least single-parent-process) application containers. (I'm also looking forward to systemd as a process manager inside e.g. Docker for more sophisticated multi-process applications which for whatever reason want to be in the same container, but that's a different use case.) While I can see the reason why you want this I really find this quite dubious in general. Much of our stack relies on /run and all those other facilities, of our general execution environment to be properly initialized, cleaned up and maintained. We do this with tmpfiles snippets, early-boot services, cron jobs, timer units, and so on and so on. Just saying no to these things, ignoring them and not executing them will only get you so far. It also creates in a way a new execution environment, unless you perfectly replicate the execution environment from your container manager, knowing all components in play, including all libraries and whatever else. If you really intend to make Fedora in general workable without providing support for tmpfiles bits, without cron jobs, without timer units, without setting up the execution environmnt the same way as on a classic Fedora boot, then please make this a clear goal of Fedora. But just trying to add this through the backdoor sounds wrong. Honestly though, I really don't think this is really such a good idea. You make things much more complicated for developers that way. We *want* developers to make use of the OS services we provide after all. It makes the system more uniform and more accessible to our admins and users. If you take the vast majority of the facilities that we provide for software away, then very little remains, you devalue the OS itself. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
Forwarding Colin's response = On Wed, Oct 15, 2014 at 09:47:41AM -0500, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@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, -- Colin Watson [cjwat...@debian.org] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 ArchVersion 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, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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...
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On Wed, Oct 15, 2014 at 05:53:41PM +, Jóhann B. Guðmundsson wrote: 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. I'm not seeing a problem here. If Peter said no way! I'm migrating to timer units, then maybe we would need to revisit. But as predicted, that's a non-issue. There really is no crisis here — we can continue to make incremental improvements as things come up, and if someone — you or anyone else! —is interested in reviving a concerted effort to do https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units, I'm all for it. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On 10/16/2014 12:03 PM, Matthew Miller wrote: On Wed, Oct 15, 2014 at 05:53:41PM +, Jóhann B. Guðmundsson wrote: 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. I'm not seeing a problem here. If Peter said no way! I'm migrating to timer units, then maybe we would need to revisit. But as predicted, that's a non-issue. There really is no crisis here — we can continue to make incremental improvements as things come up, and if someone — you or anyone else! —is interested in reviving a concerted effort to do https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units, I'm all for it. Obviously you have never had to implement features on the scale I had bumbing into the brokenness in the distribution while at it and I'm still waiting for you to picked that up, you where such an expert on the matter so man up and complete this yourself and god forbit that anyone has to clean up the mess you leave behind! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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
--
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1153638
Thanks Matthew.
Vít
[1] https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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
Re: man-db without cache update (no cron or systemd *.timer)
Once upon a time, Jan Chaloupka jchal...@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)? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
On 10/15/2014 04:47 PM, Chris Adams wrote: Once upon a time, Jan Chaloupka jchal...@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. peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 only need to enable a unit not to have a depenedency on full systemd stack (see the thread systemd dependencies from August for recent discussion). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 only need to enable a unit not to have a depenedency on full systemd stack (see the thread systemd dependencies from August for recent discussion). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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:pschi...@redhat.comsigh 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: man-db without cache update (no cron or systemd *.timer)
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 jchal...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
