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

On Wed, Feb 18, 2009 at 4:10 PM, Andreas Radke <a.radke@arcor.de> 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.

Holy smokes, did you try running the cron job? It generates an absurd
amount of output, so for those people that get email when cron jobs
produce output on stdout/stderr, this might be a bit much. Does anyone
do this, or is this really a non-concern?

> All local tests have worked well. So I start a signoff thread now.

As a drop in replacement, man, apropros, and whatis seem to be working
fine (at least after a DB generation). So you have my signoff for
x86_64.

-Dan

Am Wed, 18 Feb 2009 21:30:50 -0600
schrieb Dan McGee <dpmcgee@gmail.com>:

> Holy smokes, did you try running the cron job? It generates an absurd
> amount of output, so for those people that get email when cron jobs
> produce output on stdout/stderr, this might be a bit much. Does anyone
> do this, or is this really a non-concern?

We can for sure run mandb --quiet in the cronjob. Debian does that. But
then we will probably almost never get bugreports for broken pages.

Depending on the settings what mails you want to get from cronjobs for
stderr or stdout everybody could change that.

I'm unsure what we should set as default. Other opinions?

-Andy

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.

On Thu, Feb 19, 2009 at 2:36 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
> On Wed, 2009-02-18 at 23:10 +0100, Andreas Radke wrote:
>> 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.

> 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

> 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.

Don't Andy's and Jan's words here contradict with regard to creating a man user?

-Dan