Hi folks,
As some of you may know I've been working on updating the KDE4 recipes.
Most of the packages are now built with cmake, and I was able to build all
of them to completion. However, even though KDE is successfully launched
it's not completely operational.
The problem is old to us: the compilation prefix (eg:
/Programs/KDE-Libs/4.8.1) is used to produce some executables and
libraries. The result is that in runtime plug-ins provided by other KDE
packages will be searched for on $target/lib/kde4 rather than on
$goboLibraries/kde4. The consequence is that many plug-ins aren't found and
then applications misbehave.
The approach that we used on the /System/Index branch of the Compile and
Script tools was to use a compilation prefix (eg: /usr) and then switch to
a different prefix at install time (eg: /Programs/KDE-Libs/4.8.1). That
works fine for most packages, except for the whole KDE4 suite. In its case,
the 'install' target produces executables based on the install prefix,
which brings us back to the original problem.
Today I thought more about the issue and started to wonder why we just
don't rely on the UnionSandbox for that issue. Jonas had a very strong
opinion that FiboSandbox should never die (and in many times he proved me
he was right). I don't remember exactly how stable the port of unionfs-fuse
was back then, though, although I suspect that he also wanted to make sure
that Rootless would continue to work on environments lacking a port of
FUSE. In any case I don't think FiboSandbox needs to die, but I think that
the hacks demanded to maintain certain recipes is worth a new approach to
collecting the left-overs.
Some years ago I wrote a prototype in which both the compilation and
install prefix were set to /usr. After some recipe's install target had
executed I looked at the files left in $sandbox_rw and moved them to
$target. Back then, some problems prevented me from doing progress. If I
recall correctly, they were all related to Makefiles that either appended
or modified existing files at /bin, /etc and /usr/share. The issue is that
it's hard to tell if such files must be moved to $target or not. The Glibc
package was a notable case where some of these files needed to be moved to
$target.
Even with these problems, I believe that the long-term solution is to peek
the files in $sandbox_rw and move them to $target. I'm thinking that
unionfs-fuse could be improved to have an extended attribute (or some other
indicator) in the write branch to tell if the file already existed before
or not. If it did not exist, then we can move that file to $target.
Otherwise we can catch that with an array such as the one we define in
recipes of type Manifest:
manifest=(
/bin/foo:$target/bin/foo
/usr/share/zoneinfo:$target/Shared/zoneinfo
)
What's your thoughts on this?
Thanks!
--
Lucas
"If you're looking for a reason I've a reason to give: pleasure, little
treasure"
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
