[arch-dev-public] [signoff] man-db 2.5.3-1 replacing man

[Jan de Groot]

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.