The man-db package has a couple of useful cron files, cron.daily and cron.weekly, which the ebuild doesn't install. This is inconvenient if you want man pages regularly checked. Reproducible: Always Steps to Reproduce: 1. emerge man-db 2. 3. Actual Results: See above Expected Results: See above See above
any news on this ? man-db is a pretty convenient replacement for man :)
i dont use man-db, so if someone posted a correctly working patch, i imagine i'd commit it a lot quicker
Created attachment 234605 [details, diff] adjust permissions, provide cron script and cleanup Here it is: - disable setuid in configure (enabled by default, it contains some code related to dropping privileges that doesn't really work like I would expect it to - it doesn't allow to generate global index unless I'm doing it wrong) and set setuid bits and cache directory permissions manually. Goal - to be able to update global index even when running as non-root (so typical user when doing 'man --update' or cron in case of 'mandb'). - disable threads explicitly (needs investigation whether it's safe for gdbm backend) - provide simple cron.daily script to run mandb --quiet which generates index for 'whatis' There's also option to use /var/cache/man-db instead of /var/cache/man as this directory is used by sys-apps/man as well and may contain incompatible and no longer neccessary cruft, like /var/cache/man/whatis. Other option is to purge this dir in pkg_preinst.
Created attachment 235229 [details] man-db cron file
Yes, that cron script is from Debian, it won't work. Also I don't think we really need to ensure all privileges are set there and we may even not have means if cron is running unprivileged. I've installed cron script that does simply #!/bin/sh exec nice mandb --quiet which is sufficient in this case (permissions are ensured in package pkg_postinst and nobody else is supposed to change them - if you break them, you're doing it wrong or you know what you're doing) Mike, I'd like to move forward with this, what's your view on #3? Especially /var/cache/ man vs man-db directory issue.
what's this $TMPDIR junk ? we have $T for that. also, you use -EOF, but you dont actually indent the body with tabs. `die` on `dodoc` is garbage; dont do it i'd rather we figure out the set*id stuff and fix it upstream or fix our deployment rather than diverging in a manor no one will really be able to track back later
(In reply to comment #5) > Yes, that cron script is from Debian, it won't work. > Works for me, and has for some time. Why do you think it fails? Will
Created attachment 237761 [details, diff] man-db diff - cleanup ebuild a bit - enable-setuid (will prevent non-root users from regenerating cache, but it's apparently how it's supposed to be - at least it works like this in other distros) - clean /var/cache/man if old sys-apps/man cruft is found there @Mike dodoc || die should stay imho, at least it delivers punishment for blind version bumps (of course you can do whatever you wish, it's your package after all) @C W Rose If you look closer debian cron file uses debian-specific calls like dpkg-statoverride. Also it uses start-stop-daemon for no apparent reason. Why do you insist?
Created attachment 237765 [details, diff] ebuild diff Bummer, removed setting suid bits manually as buildsystem does it now. I've also changed fperms 6755 /var/cache/man (suid+guid) (man:root) to fperms 2755 /var/cache/man (guid) (man:root) to match debian man and mandb executables are (as a factory setting) created wich chown man:root with just suid bit (4711)
i'm not adding die to dodoc, end of story. stop wasting time on it. you `rm -rf` the dir in pkg_preinst() and then turn around and try to `chown` it in pkg_postinst(). how can that possibly work ? the inline script really should be intended: cat <<-EOF > foo ... EOF
If you look closer there's keepdir /var/cache/man in src_install chown + chmod could be probably added to cron script just before invoking mandb as well, but that's just in any case someone (un)intentionally broke permissions
that's a bit hokey/racey. only delete sub-dirs/files.
Interesting - missed the dpkg reference, but in fact (with the file absent) the script works anyway. I had assumed the "daemon" approach paid off with lower resource usage/greater security, but I may well be wrong. Anyway, the script is good starting point, and (reference the original comment) some sort of cron script is definitely needed. Will
The reason I used start-stop-daemon in the Debian cron.daily/cron.weekly scripts was to eliminate spurious syslog noise due to su opening a PAM session. It's not critical to functionality.
Incidentally, as upstream I'm more than happy to help with any problems surrounding this. I gather that this is one of the last blockers for using man-db by default in Gentoo, which I would love to see happen.
Created attachment 277183 [details, diff] man-db-2.6.0.2.ebuild.diff > that's a bit hokey/racey. only delete sub-dirs/files. Fixed. Also now properly using autotools-utils.
Created attachment 277185 [details, diff] berkdb compilation fix (for completeness sake)
Thanks for reporting the build problem when configured to use Berkeley DB. I have committed a more complete version of your fix upstream: http://bzr.savannah.gnu.org/lh/man-db/trunk/revision/1366 (Please forward such patches to me directly rather than relying on me happening to notice them in the Gentoo bug tracking system, though.)
Created attachment 291697 [details] man-db-2.6.0.2.ebuild.diff Another revamp (adjust to new static libs handling in autotools-utils)
Mike... maybe instead of rewriting the ebuild for no freakin' reason, you could use patch provided here...
(In reply to comment #19) > Created attachment 291697 [details] > man-db-2.6.0.2.ebuild.diff > > Another revamp (adjust to new static libs handling in autotools-utils) Is this patch missing anything? If not, would be nice to commit it and get man-db replace man :)
(In reply to comment #19) > Created attachment 291697 [details] > man-db-2.6.0.2.ebuild.diff > > Another revamp (adjust to new static libs handling in autotools-utils) I'm confused by the depends. !berkdb? ( !gdbm? ( sys-lib/gdbm )) So when the user doesn't have either set, pull in gdbm?
(In reply to comment #19) > Created attachment 291697 [details] > man-db-2.6.0.2.ebuild.diff > > Another revamp (adjust to new static libs handling in autotools-utils) Last comment would be to use -EOF and intend the body of the script.
(In reply to comment #22) > (In reply to comment #19) > > Created attachment 291697 [details] > > man-db-2.6.0.2.ebuild.diff > > > > Another revamp (adjust to new static libs handling in autotools-utils) > > I'm confused by the depends. !berkdb? ( !gdbm? ( sys-lib/gdbm )) So when the > user doesn't have either set, pull in gdbm? If this is the case I would rather bump the ebuild to EAPI 4 and solve it through REQUIRED_USE. Let me know if it is because I'll commit these changes along with the EAPI bump to the tree shortly.
(In reply to comment #24) > (In reply to comment #22) > > (In reply to comment #19) > > > Created attachment 291697 [details] > > > man-db-2.6.0.2.ebuild.diff > > > > > > Another revamp (adjust to new static libs handling in autotools-utils) > > > > I'm confused by the depends. !berkdb? ( !gdbm? ( sys-lib/gdbm )) So when the > > user doesn't have either set, pull in gdbm? > > If this is the case I would rather bump the ebuild to EAPI 4 and solve it > through REQUIRED_USE. Let me know if it is because I'll commit these changes > along with the EAPI bump to the tree shortly. As long as man is pulled into system, don't use REQUIRED_USE and EAPI-4 or you'll break the stage building. $ grep man $(portageq portdir)/profiles/base/packages *virtual/man
Make it a berkdb USE only and then berkdb? ( sys-libs/db ) !berkdb? ( sys-libs/gdbm )
As I commented yesterday to Cardoe in IRC, I think that we could drop gdbm USE flag and simply keep berkdb to not use gdbm only when berkdb is enabled
(In reply to comment #27) > As I commented yesterday to Cardoe in IRC, I think that we could drop gdbm > USE flag and simply keep berkdb to not use gdbm only when berkdb is enabled Will work on it and commit next week if nobody shows problems
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #22) > > > (In reply to comment #19) > > > > Created attachment 291697 [details] > > > > man-db-2.6.0.2.ebuild.diff > > > > > > > > Another revamp (adjust to new static libs handling in autotools-utils) > > > > > > I'm confused by the depends. !berkdb? ( !gdbm? ( sys-lib/gdbm )) So when the > > > user doesn't have either set, pull in gdbm? > > > > If this is the case I would rather bump the ebuild to EAPI 4 and solve it > > through REQUIRED_USE. Let me know if it is because I'll commit these changes > > along with the EAPI bump to the tree shortly. > > As long as man is pulled into system, don't use REQUIRED_USE and EAPI-4 or > you'll break the stage building. > > $ grep man $(portageq portdir)/profiles/base/packages > *virtual/man I have seen all man-db versions in the tree use, at least, eapi2, I guess the new revbump should go back to eapi0? In that case it couldn't neither use autotools-utils.eclass as it needs >=eapi2
*** Bug 439876 has been marked as a duplicate of this bug. ***
should be all set now in the tree; thanks for the report! Commit message: Install daily cronjob for building caches http://sources.gentoo.org/sys-apps/man-db/files/man-db.cron?rev=1.1 http://sources.gentoo.org/sys-apps/man-db/man-db-2.6.3-r1.ebuild?rev=1.1
