Gentlemen, scrollkeeper, gnome-vfs and anjuta all violate FHS compliance. PLease do (after emerging gentoolkit, of course): qpkg -f /usr/doc and repeat for /usr/man and /usr/info according to fhs and gentoo standards, stuff should go into /usr/share/{doc,info,man} thanks
spider@Darkmere> qpkg -f /usr/doc -v ~ gnome-base/gnome-vfs-1.0.5-r2 * gnome-base/gnome-vfs-2.0.1 * gnome-base/gnome-vfs-2.0.2 * sys-apps/baselayout-1.7.9-r1 * x11-misc/bbconf-1.6 * Hmm, Not sure about scrollkeeper.. what did you get for that? I'll take another look at gnome-vfs and see. What about wine, is that settled now? (no, I dont think /usr/wine/{lib,bin,include} is good.)
checking this some further : qpkg gnome-base/gnome-vfs-1.0.5-r2 -v -l |grep "/usr/doc" /usr/doc Darkmere root # qpkg gnome-base/gnome-vfs-2.0.2 -v -l |grep "/usr/doc" /usr/doc It appears that neither package installs -anything- under it, but makes sure the directory exists. Is this still a violation when no files are there? Especially since baselayout creates the symbolic link.
app-text/scrollkeeper-0.3.11 * dev-libs/expat-1.95.4 * dev-util/cook-2.20 * ok, including raker on this report, to see his opinion on the wines.
spider, better to not have the ebuilds even touch the /usr/doc directory. basically, they're creating the directory under ${D}
nick, phoenix: are wine and winex within FHS compliance?
neither wine nor winex is within FHS compliance. I will be looking through both ebuilds today and monday (i'll be up north this weekend with no electricity and no computer) to see if I can get things installed in a compliant manner. winex is closer... if that means anything... :)
phoenix, nick: can this bug be closed then? are wine and winex FHS compliant now?
4.7 /usr/lib : Libraries for programming and packages 4.7.1 Purpose /usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts.[footnote 18] Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. Since we have wrapper scripts in /usr/bin for the wine and winex packages and all the files in /usr/lib/wine* are not meant to be executed directly by the user, I would surmise that we are within FHS compliance. It appears that we have been using /opt for binary-only packages. One MAY argue that by the standard, /opt would be a "better place" for wine but I would disagree. By definition, i think we should consider binary-only packages /opt (ional) and wine as a standard application.
