Bug 989077

Created attachment 779045 [details]
Spec file fixes patch

Fix committed, I let the maintainer review the changes and trigger the rebuild.

Jóhann, Pierre,

requirement on crontabs was deliberately removed because of bug #806086. I understand that this is against the packing guidelines, but man-db package doesn't need cron for it's core functionality. (Man-db's cron job creates and updates indexed database of man pages, which is then used by tools like apropos and similar; displaying man pages doesn't require this db).

Please, review the referenced bug and described conditions and confirm back that you still insist on crontabs requirement.

To clarify, I'm not against the packing guidelines. If you say that crontabs must be in requires, I'll accept Pierre's patch, which looks good. But in my humble opinion, there's no need to pull crontabs as dependency because of man-db, for, lets say in some minimal installation of Fedora.

peter

Hi Peter,

Thanks for the quick answer. I might say something silly but what about creating an -update subpackage which would contain the cron file and requires man-db and crontab.

Would this make everyone happy?

I might mean comps might be adjusted to required man-db-update instead of man-db on some groups, but then minimal install can require just man-db.

That sounds like unnecessary overkill.  I'm with Peter on this; if cron is there, great, if not, whatever.  It's optional.

The problem with that, as I see it, is that man-db WON'T then pull in cron, which could cause confusion if one expects it to regularly update itself. Since rpm's dependencies are all hard, "whatever" package relationships can't be formally described. A subpackage is the clearest way of indicating that relationship.

If I install man-db on a system that doesn't have cron, and I see that it creates /etc/cron.daily/man-db, I might naturally expect that it's going to update itself — especially if /etc/sysconfig/man-db is also installed and includes CRON="yes". It'd be far too easy to overlook that cron itself wasn't actually pulled in as a dependency.

By the same token, if I'm removing cron from a system, and I want to know what the effects will be, seeing that it will also trigger the removal of man-db-update gives a clear indication that it will halt regular man-db updates. Having no sign of that dependency whatsoever turns that effect into a hidden side-effect.

An -update package may seem like "overkill", but it's only a few lines in the spec file, to split out (by my count) 2 of man-db's 108 files and add a couple of dependencies. And it will avoid problems with either "whatever" dependencies not being formally defined, or hard dependencies over-defining relationships.

(As it is right now on my F19 system, removing cron would cause a cascade removal of the entire virtualization system, because unbound-libs depends on crontabs. Which makes me think the packaging guidelines referenced above should be updated to at least suggest -update packages, rather than simply adding a crontabs requirement to any package containing an optional crontab... because I agree that's really not productive.)

(In reply to Colin Watson from comment #5)
> That sounds like unnecessary overkill.  I'm with Peter on this; if cron is
> there, great, if not, whatever.  It's optional.

The correct dependency on coreOS baseOS components is not optional and makes the life of us that are working on cleaning up and correcting the dependency on the components in it much more difficult as well as those users that have grown custom and expect things to just work if installed. 

We remove something from the core/baseOS and suddenly things stop working and we had no idea because we thought only x amount of packages actually depended on the component being removed. 

So either fix the dependency or if it's strictly not required create an sub-package with cron-job and have it depend on crontabs as Pierre suggested.

Jóhann,

would it be OK if man-db migrated to the systemd timer?

peter

(In reply to Peter Schiffer from comment #8)
> Jóhann,
> 
> would it be OK if man-db migrated to the systemd timer?
> 
> peter

No since by doing so you would add a hard dependency on systemd in man-db.

We will only migrate cron jobs for components that already are or should be depending on systemd which is ca half of the cron jobs in the distribution.

I see. Now, for man-db, it's dependency on cron vs systemd. What's the scenario when the systemd is not available in the system? (If it was already discussed/described somewhere you know of, simple link or reference is OK for me.)

Thanks.

peter

(In reply to Peter Schiffer from comment #10)
> I see. Now, for man-db, it's dependency on cron vs systemd. What's the
> scenario when the systemd is not available in the system? (If it was already
> discussed/described somewhere you know of, simple link or reference is OK
> for me.)
> 
> Thanks.
> 
> peter

Irrelevant the main headache going through the init switch was those components that just magically expected things to be there for eternity those where the component that caused the most headache and broke things for most people. 

The fact is man-db has absolutely no purpose being migrated to native systemd units.

Looking at the cron job I have to ask why do we need to recreate man page indexes and the whois database daily if no package was installed?

Well, there's no need for cron. Man DB could be updated with some rpm trigger for all packages - when packages are installed/updated/removed. However, depending on number of man pages available in the system, this can take some time. Especially creating the DB. Therefore, I better would not use such a trigger in the installation process and because of that, cron job exists.

I know that upstream is working on optimization of mandb command, but it's not ready yet. When this is done, we might reconsider using the rpm trigger.

So for now fix the dependency on cron and close this bug. 

In the future implement components man pages in separated man sub-package which depends on mandb and runs this rpm trigger when install?

I'm closing this bug as man-db already depends on crontabs in rawhide.

For the future, man-db cron should be removed and man-db database should be updated with rpm trigger. Before that however, mandb command needs to be optimized.

Thanks,

peter

Just a side node there was some talk on trimming down Fedora installed size  thread -devel splitting out man pages into separated subpackage and if that turns out to be the case obviously that rpm trigger should be used for those compnents as well as "man-page-not-found" with same concept as is behind "command-not-found" added to the man-db package.