Or: "Lions and tigers and ebuilds, oh my!"

Yes, I know there are no official packages for Gentoo yet.  I decided to see
if I could do something useful by installing what unofficial ones were available
and probing for bugs, and possibly rolling a few ebuilds of my own for the
packages that haven't gotten any love yet. I used non7top's GitHub fork of
Serghei's ebuild repository (at the time I started, the contents of the two were
identical, actually) and did manage to get kdebase installed after two ebuild-
related hiccups.

After that, things started to get complicated, and I ran into a variety of
problems.  Unfortunately, I haven't been able to decide whether some of
them are Trinity bugs, ebuild bugs, or just Gentoo quirks, so I don't know
where to file them and need help with the triage.

__________________

Problem #1: Unset environment variables

When I first booted Trinity, the desktop *appeared* to come up exactly as
it should, but most applications would not start, the main menu was nearly
empty, and kcontrol had no settings available.  After some mucking around,
I discovered that there was no mention of the Trinity bin directory in my
PATH, and then found that Gentoo set PATH, ROOTPATH, LDPATH, and
XDG_DATA_DIRS inside a distro-specific part of starkde (for KDE 3.5.10,
that is), so I copy-and-pasted those into the startup file provided. (I know
there are some setters in the Trinity startup script.  They didn't work,
possibly because of Problem #4.)

Unfortunately, that didn't fix things--I also needed to set LD_LIBRARY_PATH
for programs (including konsole) to start properly, and XDG_DATA_HOME, 
XDG_CONFIG_HOME, and/or XDG_CONFIG_DIRS (I never tried setting
them individually, so I can't narrow it down) to get a working menu and kcontrol.

I don't know what changed between KDE 3.5.10 and Trinity 3.5.13 to make
the setting of those additional environment variables necessary, so I'm not
sure who owns the second half of the bug.

__________________

Problem #2: Autotools packages and ebuilds

I did manage to write some successful ebuilds (I have most of kdegraphics and
kdeartwork working, if anyone wants ebuilds for those, plus kdebase-meta and a
variant ksmserver ebuild with a hal useflag), but only for packages that have been
ported to CMake.  The autotools packages Will Not Work, no matter how I mangle
the KDE 3.5.10 ebuilds (rewriting from scratch is not an option, IMAO--the old
kde-meta eclass contains several hundred lines of bash script, and spending more
than minimal time on a build system that's going away is wasted effort).

After a lot of playing around with kdetoys, I was able to figure out that I was
running into two problems: a minor change in the tarball structure (not a bug, solved
by a 1-line fix), and a set of missing build/config files.  The kdetoys-3.5.10 tarball
contains a bunch of files at the top level that are missing from its 3.5.13 equivalent:
configure.in, acinclude.m4, aclocal.m4, and several other config* and Makefile*
files.  When I copied these files from the old to the new package, the ebuild got
as far as actually configuring/building the package (and, naturally, failed, because
the old buildscripts didn't know about TQT, but it was the first iteration that didn't
bail out while trying to find the build directory or run eautoreconf/aclocal).

I know next to nothing about autotools, so I don't know if those files were
removed for a reason.  Maybe someone who knows more about autotools
and ebuilds could do something without them; I just know that *I* can't.

Another thing is that I couldn't seem to get the --without-arts switch to work,
but with the ebuilds so messed up to begin with it's difficult to tell whether
that's meaningful.

__________________

Problem #3: CMake failures

Ebuilds for two subapplications of kdeutils that were included in the stuff I took from
GitHub failed to build, complaining that they weren't able to find tqt.h (one of them would
have been Ark).  I don't know whether this is an ebuild or a CMake bug.

__________________

Problem #4: startkde/starttrinity and minimal or unusual builds

While I was wrestling with Problem #1 above, I had occasion to examine both
the new and the old startup scripts in detail, and there were some things in the
new one that drew my attention. However, I'm not sure they really qualify as bugs:


if [ -d /opt/trinity/games ]; then

That, and the lines that follow it, might work fine if Trinity is installed into
/opt/trinity/, but Gentoo's practice is to install most software into /usr/.
Something like:

if [ -d ${KDEDIR}/games ]; then

might be more portable.


# Make sure a default wallpaper is set.
if [ ! -e $kdehome/share/config/kdesktoprc ]; then
 # With Trinity this file should exist, but test first.
  if [ -r /usr/share/wallpapers/isadora.png.desktop ]; then
cat >$kdehome/share/config/kdesktoprc <<EOF
[Desktop0]
Wallpaper=isadora.png
WallpaperMode=Scaled
EOF
  fi
fi

Not having a wallpaper set is harmless--these lines seem to add complexity to 
the script for no good reason (and I don't have a /usr/share/wallpapers, either--
isadora.png is in /usr/kde/3.5/share/wallpapers--so this code isn't portable).
Perhaps it belongs in a distro-specific patch?


# Configuration of the gtk_qt_engine if not already set.
[...]

Trinity will run quite happily without gtk-qt-engine installed, so a test needs
to be made for that (at minimum--I'd relegate this to "distro-specific" too).


# Remove moodin cache if we have a new wallpaper installed, jriddell. Distro-specific.
if [ -d $kdehome/share/apps/ksplash/cache/Moodin/kubuntu ]; then
  if [ /usr/share/wallpapers/kubuntu-wallpaper.png -nt $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ ]; then
    rm -rf $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/
  fi
fi

This says right out that it's a Kubuntu patch.  It doesn't belong in vanilla Trinity.


$KDEDIR/bin/artsshell -q terminate

Arts is another optional component that Trinity can operate without, so it shouldn't
be shut down without testing to see if it's there. Maybe:

if test -e $KDEDIR/bin/artsshell ; then artsshell -q terminate ; fi


(The prelinking stuff isn't in my old startup script either, but I suspect that Gentoo may
have removed it.)

__________________


I think that's everything.  The other (minor) bugs I ran into I'm fairly sure I know where
to file.