Arch Linux

I have complained about this in the past. I actually put the manpage of an upstream project (sonata) in the wrong place because I assumed Arch would be putting the manpage in the same location as every other distro - I got many bug reports over it. I hope Arch will fall in line with other distros on this matter.

Imho we should follow the FHS when it ever possible. In this case it even makes a lot of sence to put man pages into /usr/share. (this is only my very own personal oppinion; I did not think about the consequnces of our current set of packages)

I agree - man.conf already contains all the mappings to make this change easy.

Would someone mind testing a few packages to make sure we can roll this out properly? If that works, Dan, we could simply change the path that man pages are moved to in makepkg for the 3.1 release.

We should be able to just not move them at all, which would be ideal.

<http://projects.archlinux.org/git/?p=pacman.git;a=blob;f=scripts/makepkg.sh.in;h=0ef0e521540cf8211ede9636e900184c6d7df27c;hb=9615d82343148301884bfc79d87e2f408aad64bd#l716>

This would remove 8 lines of code, woohoo!

OK, so I built the latest pacman-git package without having it move the manpages from /usr/share/man/*. Findings:

Our man setup is stupid. Why have people been setting $MANPATH? Completely unnecessary since man itself does a better job finding your man folders, including ones in opt. I couldn't view manpages in /usr/share/man/* until I did an "unset MANPATH" in my shell.

Solutions? Short term is to just add /usr/share/man to the MANPATH variable so it "just works". Long term is to remove MANPATH completely from our system as it is completely unnecessary.

Things on my system that play with manpath: csh (csh.cshrc), jdk (profile.d/jdk.sh), jre (profile.d/jre.sh), kdelibs (profile.d/kde.{sh,csh}), qt3 (profile.d/qt3.sh). I'm sure many other programs that install in opt/ do it too.

Thoughts? We should really kill this $MANPATH nonsense, its killing us.

Below is a list of files that I found in core & extra when grepping for MANPATH, and have fixed locally in my CVS checkouts. Some of these do not set MANPATH, but do change the default location of man page installation.

core:
-----
base/bash/profile (removed manpath and added an "unset MANPATH" line at end to kill other bad scripts actions- is this acceptable?)
base/man/whatis.cron.daily

extra:
------
daemons/mdnsresponder/PKGBUILD
devel/jdk/jdk.profile
games/xbl/PKGBUILD
kde/kde-common/kde.tcsh
kde/kde-common/kde.profile
lib/qt3/qt.profile
network/hping/Makefile.patch (did not fix)
system/tcsh/csh.cshrc
system/root-tail/PKGBUILD
system/zsh/zprofile
system/jre/jre.profile

Don't touch /etc/profile just yet - I want to make a few changes to that in a different light.

In addition, I'd like to see if there's a way to fix this without removing MANPATH. People can still set this on their own, and saying "whoops MANPATH broke your shit" isn't a good idea.

Thus the reason I added my other bug to it in related bugs. :)

Adding /usr/share/man to MANPATH is the quick and dirty solution, but once again setting things that didn't ever need to be set is killing us here.

From Aaron's last Status Report: "Users are encouraged to report packages which EXPLICITLY use /usr/man in the PKGBUILD (perhaps through a configure option) via the bug tracker."

Well, I like grepping through /var/abs (for "usr/man" in this case), but I didn't feel like opening >100 bugs, so I've attached a list.

Some notes:
- In the vast majority of cases it's a PKGBUILD that manually installs files to $startdir/pkg/usr/man in build()
- When a package got listed twice because it's also in testing, I've deleted the non-testing line
- There was one package (filesystem) in testing that already got adapted for /usr/share/man.
- That leaves 160 packages affected; probably more or less, I doubt that the simple grep caught everything.

I'll open a new bug with another list for community (100 pkgs).

Oops, here is it:

Thanks, I've added a dev todo list with your package list.

can we get an updated /etc/profile pushed to current? there are packages updated for this in current which are broken without the manpath change. for example "man xorg.conf" doesn't work today. /etc/profile is still the old version from bash. here's a list of packages i have installed that use the new path and so have "missing" man pages:

devilspie e2fsprogs gnome-desktop gnome-panel gnome-utils imagemagick syslinux thunar vbetool xmlto xorg-server xorg-xinit

This explains why I couldn't do "man 8 pacman", doing "MANPATH=/usr/share/man man 8 pacman" works though, so I also would like to see an updated /etc/profile.

Aaron- fixed with the move of filesystem/bash/man to core?