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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux