On Wed, 2009-02-18 at 23:10 +0100, Andreas Radke wrote:
I've built man-db based on the package in community adding some changes I have found in a very good written page in the LFS book:
http://www.linuxfromscratch.org/lfs/view/6.4/chapter06/man-db.html
You can read there all about man page encoding and the expected locations and how to recode them. Therefor I have added the LFS recode script. This will allow us to recode broken man-pages when we will get bugreports. This should improve the current situation a lot.
Maybe we should write down later into the packager guide how to fix broken manpages, maybe even into the public wiki.
I didn't want to add a new system user "man" as the community package does. It seems to run fine without serious security concerns for me. If you think different feel free to drop a mail here.
It's not critical to create a database after installation. So I left out any install message. The cronjob will do this on its next run. You can surely run mandb manually to see how it goes.
All local tests have worked well. So I start a signoff thread now.
-Andy
Some notes about man-db.install: post_install/post_upgrade: chown -R man.users -> chown -R man:users. The . syntax is not POSIX compliant and I still have no idea why linux accepts this bullshit pre_remove that runs /bin/true: remove this function, it shouldn't be needed anymore with recent versions of pacman. An alternative to running /bin/true is just "return 0" instead btw. post_remove: you remove the man user, which leaves a /var/cache/man directory with files owned by an unknown user. This is a security bug, as the user is created with a >1000 userid also. When adding a new user afterwards, the user owns /var/cache/man. Either don't remove the user on post_remove, or delete /var/cache/man with it.