Bugzilla Bug 63637

In the configure in the kde.eclass

./configure \
 ${myconf} \
 --libdir="\${exec_prefix}/$(get_libdir)" \
 || die "died running ./configure, $FUNCNAME:configure"

compared to ebuild.sh

./configure \
                        --prefix=/usr \
                        --host=${CHOST} \
                        --mandir=/usr/share/man \
                        --infodir=/usr/share/info \
                        --datadir=/usr/share \
                        --sysconfdir=/etc \
                        --localstatedir=/var/lib \

As such programs that depend on the kde.eclass for mandir, infodir, etc setting install these arguements to the default /usr/{man,info} locations. e.g. kover and undoubtly many others. Thus resulting in a QA fault.

qpkg -f -nc -v /usr/man will give you part of the extent of the problems

Similar problems may also occur with the following eclasses:
aspell-dict.eclass seemant@gentoo.org
crosscompile.eclass (still used?)
embassy.eclass ribosome@gentoo.org
gnustep-old.eclass fafhrd
gnustep.eclass fafhrd

probably should of mentioned that most eclasses call econf directly.

Fixed for embassy.eclass (thanks for the tip) but I don't think it was
problematic since all EMBASSY packages are developed by the EMBOSS team and use
the same directory structure and help system (no man or info pages).

I think we can fix this in the kde.eclass by doing something like this:

if [ $PREFIX eq "/usr" ]; then
  myconf="$myconf --mandir=/usr/share/man --infodir=/usr/share/info"
fi

or something to that effect.  mainly, we don't want to set those directories like that if we're installed kde-base packages.

if this solves other kde programs and doesn't break kde-base go for it.

kde.eclass should now be fixed.

Thanks Caleb looks and works good.

Armando, is this something you want to do for gnustep?
Seemant how bout aspell-dict.eclass?

Just a note on thoughts for the GNUstep stuff relating to this.

There has been dicussion on the gnustep mailings lists about the quite sensical ability to put the gnustep-make and gnustep-base (esp. -base) packages in the regular /usr directory layout, rather than under .../GNUstep.  However, this is generally not what I'm focusing on, as the GNUstep under Gentoo support I'm aiming for will support a quite NeXT-like setup, and even if just -base is installed for NSObject and such support in objc program writing, it'll be usable installed in /usr hierarchy, or .../GNUstep, so no reason to make to install options, at this point.

However, the man and info files are generally for setting up GNUstep on the base system, through actual underlying system utilities, so I'll definitely apply this changes for those directory configure options.

Now if this thread on gentoo-dev about where to put KDE/GNOME would come to some sort of conclusion, that'd point me in the right direction for GNUstep, which is a whole other can of worms...

gnustep-old.eclass will soon go the way of the dodo, and I'm fearful of touching that file in general, so I'll leave that one be for now ;-)

So, it seems this is assigned to me ... not sure what I have left to do
exactly.

The gnustep-old.eclass i'm not going to fix, as I will soon be removing it
(likely within a month). gnustep.eclass (the new one) uses econf.

In regards to the very first comment:
# qpkg -f -nc -v /usr/man
sys-apps/baselayout-1.9.4-r3
...is this correct, or no?

Armando - assignment problem fixed. You've considered this and have come to a
good conclusion. Baselayout has a /usr/man symlink to /usr/share/man just in
case some ebuilds don't follow the rules(tm).

Seemant - have a check and see if aspell-dict.eclass needs to change otherwise
this can be closed.

Danger Will Robinson.  Baselayout is actually *removing* /usr/man, /usr/doc and
/usr/info symlinks starting with the 1.11 series.  So, the gnustep stuff should
be re-thought.

the aspell dictionaries are rather unorthodox, actually -- there are no
configure options.  All the configure script does is recognise where aspell is
installed and then proceeds to make according to that.  The DESTDIR variable in
src_install takes care of the final locations. Punting back to armando, for the
gnustep issues.

I've come to the conclusion that this problem generally doesn't exist for
GNUstep related applications.  This is because by default, man and info pages
from GNUstep libraries and apps install into
/`gnustep-install-domain`/Documentation/man (or info).  (Even though econf is
specifying mandir and infodir otherwise! *sigh*)

Of course this opens up a whole other area to consider, which is a "GNUstep has
it's own FHS" sort of discussion, but it doesn't use the old /usr/man (or info)
directories, which is what this bug is about.

Not sure who to punt this back to for now, so giving back to seemant as he
knows more than I do. :-)

seems to be all resolved.  Dragonheart?

Seemant - all good.

Armando - time to remove gnustep-old.eclass

No longer used according to my fgrep -r gnustep-old . --include "*ebuild"

we don't remove old eclasses.  If they were ever in a stable ebuild they must
stay in the portage tree until a future version of portage supports eclass
removal.