Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#8839 - Arch Linux should use /usr/share/man for manpages

Attached to Project: Arch Linux
Opened by Dan McGee (toofishes) - Wednesday, 05 December 2007, 02:04 GMT
Last edited by Aaron Griffin (phrakture) - Monday, 04 February 2008, 15:32 GMT
Task Type Feature Request
Category System
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity Low
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 14
Private No

Details

Arch currently (through makepkg) puts all manpages in /usr/man.

The FHS (http://www.pathname.com/fhs/) specifies that manpages should be at /usr/share/man, because the /usr/share hierarchy contains architecture-independent data and manpages are just that- architecture independent. There is no /usr/man directory specified by FHS.

Invalid reasons to close this bug:
1. "The current way is the Arch way"

Thoughts, questions, comments? If we did do this, we wouldn't have to do a full rebuild- incrementally would be fine.
This task depends upon

This task blocks these from closing
 FS#9356 - pacman man page is broken at x86_64 
Closed by  Aaron Griffin (phrakture)
Monday, 04 February 2008, 15:32 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented, excepting package rebuilds which will come in time
Comment by Scott H (stonecrest) - Wednesday, 05 December 2007, 03:02 GMT
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.
Comment by Pierre Schmitz (Pierre) - Wednesday, 05 December 2007, 09:25 GMT
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)
Comment by Aaron Griffin (phrakture) - Wednesday, 05 December 2007, 16:55 GMT
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.
Comment by Dan McGee (toofishes) - Wednesday, 05 December 2007, 17:19 GMT
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!
Comment by Dan McGee (toofishes) - Sunday, 09 December 2007, 07:31 GMT
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.
Comment by Dan McGee (toofishes) - Sunday, 09 December 2007, 07:46 GMT
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
Comment by Aaron Griffin (phrakture) - Monday, 10 December 2007, 17:38 GMT
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.
Comment by Dan McGee (toofishes) - Monday, 10 December 2007, 18:00 GMT
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.
Comment by Jens Adam (byte) - Sunday, 13 January 2008, 11:36 GMT
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).
Comment by Jens Adam (byte) - Sunday, 13 January 2008, 11:37 GMT
Oops, here is it:
Comment by Aaron Griffin (phrakture) - Monday, 14 January 2008, 17:18 GMT
Thanks, I've added a dev todo list with your package list.
Comment by Jonathan Frazier (wide-eye) - Tuesday, 22 January 2008, 17:04 GMT
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
Comment by Fredrik (vEX) - Tuesday, 29 January 2008, 10:22 GMT
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.
Comment by Dan McGee (toofishes) - Saturday, 02 February 2008, 15:59 GMT
Aaron- fixed with the move of filesystem/bash/man to core?

Loading...