Hi, i recently tried to install CMUCL,which requires LessTif. CMUCL failed to build because it did not found the lesstif headers. after looking at the Lesstif file list. i noticed that it installed nearly everything(headers,docs) into /usr/LessTif/. This causes other packages to break and violates the file hierachy standard (not the first time in gentoo). installing lesstif to /usr might be a solution.
bartron, lanius I do not agree with the /usr/LessTiff layout. If anything it should be in /usr/X11R6/ or so. Also, please make sure packages which call lesstiff (or virtual/motif) as a dependency can compile and run with the new layout.
Proposal for an FSHish solution: install LessTif things into /usr/X11R6/{include,lib}/LessTif/ and openmotif things into /usr/X11R6/{include,lib}/OpenMotif/. and create links into /usr/X11R6/{include,lib} as needed (depending on a package requirering LessTif or OpenMotif). the version of LessTif's and OpenMotif's libraries differs e.g. libXm.so.1 and libXm.so.3. so they can life side-by-side in /usr/X11R6/lib. no extra search path for the runtime linker is required because these files do not conflict. Header files and .so files _do_ conflict. so it's needed to add right {C,CXX,LD}FLAGS to have applications find the libs/headers in the right directories. Or Perhaps portage detects wether a package needs lesstif,openmotif or if it does not matter at all and creates symlinks for the headers and libs into /usr/X11R6/{include,lib} before building the program. only an idea not mature...
I'd vote for: /usr/X11R6/[Ll]ess[Tt]if /usr/lib/[Ll]ess[Tt]if # similar to qt on many distros [*1] - *1) FHS only says that large packages mustn't use a dir *directly* under `/usr', so `/usr/lib' should be ok. - or the original layout that is still used by RedHat today: /usr/X11R6/LessTif/ Motif1.2/ bin/ include/ lib/ doc/ /usr/X11R6/lib libMrm.so.1{,.0.2} -> ../LessTif/Motif1.2/lib/libMrm.so.1{,.0.2} libUil.so.1{,.0.2} -> ../LessTif/Motif1.2/lib/libUil.so.1{,.0.2} libXm.so.1{,.0.2} -> ../LessTif/Motif1.2/lib/libXm.so.1{,.0.2}
[somehow missed comment #2, should have pressed `reload' first...] Thomas: My personal opinion is that Openmotif (2.1, that is) is too much of an industry standard to be put in a nonstandard location. The current plan is to leave Openmotif in `/usr/X11R6', put Lesstif into its own, isolated tree, and symlink runtime- accessible parts (shared libs) from `/usr/lib' or `/usr/X11R6/lib'. That way, non-ebuild based packages still find Openmotif without additional flags. Ebuilds that intend to build against Lesstif just need to prepend `-{IL}$LESSTIF_DIR/{include,lib} to their compiler and linker options (and $LESSTIF_DIR/bin to $PATH during build if there ever should be one that needs uil). Seemant: with the eclass approach, only necessary change is "LESSTIF_DIR" in lesstif.eclass.
I still believe that having something like a `LessTif dir' is not the right thing. this is not the FHS way in doing thing. rather put an lesstif subdir into /usr(/X11R6)?/lib and /usr(/X11R6)?/include.
this ebuild should still be masked as we are working on it
re comment #5: For simple packages that install nothing more than libraries and headers, I agree that an additional subdir under `lib/' and `include/' may be (is) a better solution (see xaw3d, for example). However... Lesstif also comes with binaries and manual pages with the same name as Openmotif's. Since Openmotif's manual pages, even though they document the same material, are generally more detailed, they should take precedence if both are installed (by putting Lesstif's manpages in their own dir that comes *after* `/usr/X11R6/man' in MANPATH (config variable?)) (*1). The files in `bin/' are usually not run manually and don't have to be in PATH at all. So since we definitely need a $LESSTIF_DIR for `bin/' and `man/', there's no easy way to be 100% standards compliant... or maybe FHS simply does not cover this special case. (suggestions are of course more than welcome) - *1) Actually, since Openmotif appends `x' to manpage sections while Lesstif does not, they'll both be visible in xman or equivalents.
please discuss this further in bug #29388 *** This bug has been marked as a duplicate of 29388 ***