https://bugzilla.redhat.com/show_bug.cgi?id=870694
Bug ID: 870694 QA Contact: extras-qa@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: bos@serpentine.com, haskell-devel@lists.fedoraproject.org, petersen@redhat.com Assignee: petersen@redhat.com Summary: excessive hourly cron job Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: pwouters@redhat.com Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: ghc Product: Fedora
Description of problem: ghc installs /etc/cron.hourly/ghc-doc-index. I find this problematic for various reasons.
First, it seems this "documentation" can only come from package installs, so it seems to be better places in an ghc spec macro or %post job.
Second, if there are really good reasons to keep this in, hourly is _way_ too often. I would suggest weekly at most.
Third, it seemed to blow up for me too:
Date: Sat, 27 Oct 2012 20:01:02 From: Cron Daemon root@bofh.nohats.ca To: root@bofh.nohats.ca Subject: Cron root@bofh run-parts /etc/cron.hourly
/etc/cron.hourly/ghc-doc-index:
--read-interface=Cabal-1.14.0,Cabal-1.14.0/Cabal.haddock --read-interface=array-0.4.0.0,array-0.4.0.0/array.haddock --read-interface=base-4.5.0.0,base-4.5.0.0/base.haddock --read-interface=bytestring-0.9.2.1,bytestring-0.9.2.1/bytestring.haddock --read-interface=containers-0.4.2.1,containers-0.4.2.1/containers.haddock --read-interface=deepseq-1.3.0.0,deepseq-1.3.0.0/deepseq.haddock --read-interface=directory-1.1.0.2,directory-1.1.0.2/directory.haddock --read-interface=filepath-1.3.0.0,filepath-1.3.0.0/filepath.haddock --read-interface=ghc-prim-0.2.0.0,ghc-prim-0.2.0.0/ghc-prim.haddock --read-interface=hashable-1.1.2.3,hashable-1.1.2.3/hashable.haddock --read-interface=hashmap-1.0.0.2,hashmap-1.0.0.2/hashmap.haddock --read-interface=integer-gmp-0.4.0.0,integer-gmp-0.4.0.0/integer-gmp.haddock --read-interface=mtl-2.1.1,mtl-2.1.1/mtl.haddock --read-interface=old-locale-1.0.0.4,old-locale-1.0.0.4/old-locale.haddock --read-interface=old-time-1.1.0.0,old-time-1.1.0.0/old-time.haddock --read-interface=parallel-3.2.0.2,parallel-3.2.0.2/parallel.haddock --read-interface=parsec-3.1.2,parsec-3.1.2/parsec.haddock --read-interface=pretty-1.1.1.0,pretty-1.1.1.0/pretty.haddock --read-interface=process-1.1.0.1,process-1.1.0.1/process.haddock --read-interface=text-0.11.2.0,text-0.11.2.0/text.haddock --read-interface=transformers-0.3.0.0,transformers-0.3.0.0/transformers.haddock --read-interface=unix-2.5.1.0,unix-2.5.1.0/unix.haddock --read-interface=unordered-containers-0.2.1.0,unordered-containers-0.2.1.0/unordered-containers.haddock
In short, I would strongly suggest removing this cronjob altogether.
https://bugzilla.redhat.com/show_bug.cgi?id=870694
Garrett Holmstrom gholms@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gholms@fedoraproject.org
--- Comment #1 from Garrett Holmstrom gholms@fedoraproject.org --- You (the maintainer) can get rid of the delay between package installation and doc-readiness by running that in every package's %post instead. If the number of times it might run in a large rpm transaction bothers you then you can instead employ %posttrans and a temporary file to run it at most once per transaction:
1. Add a new /var/lib/rpm-state/ghc directory to the ghc package. 2. Add a new, %ghosted /var/lib/rpm-state/ghc/update-doc-index file to the ghc package. (This specific file name is merely illustrative.) 3. Have every Haskell package's %post and %preun script touch /var/lib/rpm-state/ghc/update-doc-index. 4. Add a %posttrans section to every Haskell package that checks if /var/lib/rpm-state/ghc/update-doc-index exists, and if it does, it deletes that file and then updates the doc index. This is a great candidate for an rpm macro.
How to deal with a transaction that removes ghc from the system completely is left as an exercise to the reader.
Relevant packaging standard: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Saving_state_betwe...
https://bugzilla.redhat.com/show_bug.cgi?id=870694
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #2 from Jens Petersen petersen@redhat.com --- Thanks for bringing this up - for long I was not completely happy with the cronjob hack either but hadn't found time to look into a better solution yet.
Paul: I wonder why it failed for you? Is above the complete cron mail?
Let me make a few comments on the current cronjob:
- it was indeed introduced because running in %post slowed down installation of ghc-*-devel very considerably when there are many libs installed/being installed
- the cronjob runs as root which is also highly undesirable
- the cronjob is hourly but basically uses 0 cpu unless any ghc-*-devel have been newly installed/updated.
I will move to using /var/lib/rpm-state/ghc/ as soon as possible. Running once per rpm transaction in %posttrans should be no problem.
https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #3 from Jens Petersen petersen@redhat.com --- Thanks, I have committed:
http://pkgs.fedoraproject.org/cgit/ghc.git/commit/?id=483b090ae726f0770c0668...
and
http://pkgs.fedoraproject.org/cgit/ghc-rpm-macros.git/commit/?id=9e0aa2550c8...
into the master branches and after testing will push to koji.
https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #4 from Jens Petersen petersen@redhat.com --- Ok, I forgot about %postun, otherwise ghc-rpm-macros seems to be working well for me.
The only problem then I see is that posttrans is not run for removal so maybe we have to run the reindex for each %postun which will slow down removals but maybe that is ok for now.
https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #5 from Jens Petersen petersen@redhat.com --- BTW I am seeing the output from gen_contents_index mentioned in comment 0. Perhaps I need to silence it - not sure why that is happening.
Of course even running gen_contents_index only once does slow down ghc-*-devel installs/updates quite a bit. I am almost wondering if it would be better to just not generate the doc index though it is nice to have or to try to hack up some debian style at job??
https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #6 from Jens Petersen petersen@redhat.com --- (In reply to comment #5)
BTW I am seeing the output from gen_contents_index mentioned in comment 0.
Ah that seems to be due to a change in the ghc-7.4 script I hadn't noticed.
https://bugzilla.redhat.com/show_bug.cgi?id=870694
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #7 from Fedora Update System updates@fedoraproject.org --- ghc-7.4.1-6.4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/ghc-7.4.1-6.4.fc18
https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #8 from Fedora Update System updates@fedoraproject.org --- ghc-7.4.1-6.4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=870694
--- Comment #9 from Jens Petersen petersen@redhat.com --- I started thinking about using 'at' instead of 'cron' but it is a bit more complicated. For now I reverted the rpm-state changes in git master and moved the cronjob to a new optional subpackage ghc-doc-index. It may be backported later to F18.
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=870694
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution|--- |ERRATA Last Closed| |2012-11-28 02:31:30
haskell-devel@lists.fedoraproject.org