GoboLinux Compile -- A Scalable Portage?

LodeRunner writes "The GoboLinux team, featured about a year ago for creating a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead, just released a new release where they introduce their own alternative to Portage and similar systems: Compile. But is yet another source-based compilation system needed?" Read a bit more below on why the GoboLinux folks think so.

LodeRunner continues "We already have ebuilds, RPM .spec files, and whatnot. The argument for reinventing the wheel yet again was the observation that while developing apps to handle these files is easy, the task of maintaining the ever-growing database of compilation scripts is the real problem -- the huge package collection of Debian comes to mind. Compile took the extreme minimalistic approach, and its scripts ("recipes") are as small as can be: the script for a typical autoconf-based program takes two lines.

Knowledge for handling common situations is usually added to Compile itself instead of being coded in the script (for example, apps that need a separate build directory just add a needs_build_dir=yes line). The plan is to make Compile as smart as it can and the recipes as small as possible.

It remains to be seen whether this experiment of gauging differently the tradeoff between flexibility and simplicity will prove itself to be limiting or enlightening, but in the ~six months Compile has been in beta test by the people from the GoboLinux mailing list, over 500 recipes were written, ranging from Glibc and GCC up to KDE and the Linux kernel itself."

Comments

A job for ln?

[sweet 'n sour]

/System/Settings/X11

mkdir /System

mkdir /System/Settings

ln -s /etc/X11/ /System/Settings/X11

Couldn't this also work?

"as simple as possible"

[scrytch]

Yes, an autoconf build script contains two lines. And cannot express version dependencies that the autoconf build didn't think to maintain ... and if it did, it doesn't communicate the dependency back to the build system. It has no way to merge config files. It doesn't even have a way to enumerate the installations. But yes, you could build a system that simple, because it's good enough for some, but even slackware isn't that simple. To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.

This isn't to say it'll get to be as complex as portage, but it will probably have to get at least as complex as ports. Which then begs an obvious question...

Re:"as simple as possible"

[HishamMuhammad]

And cannot express version dependencies that the autoconf build didn't think to maintain ... and if it did, it doesn't communicate the dependency back to the build system.

There is a separate Resources/Dependencies file, which is automatically generated with ldd (but can be hand-tuned). This is further integrated with the GoboLinux fs-oriented concept of dependencies, so if you, say, compiled Allegro "by hand", it will not complain "Allegro is missing" just because it was not built with Compile.

It has no way to merge config files. It doesn't even have a way to enumerate the installations.

Could you clarify on those? I really did not get it (and maybe that's why it's not implemented :) )

To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.

Distribution patches are applied if found in the recipe directory (a recipe is a .tar.bz2 containing a directory and some files). Configuration is being discussed in the mailing list, but currently we rely on configuration detected by autoconf et al: usually, if you have svgalib installed, program foo gets compiled with svgalib support compiled in, and vice-versa. It works well for a surprising number of packages, but yes, we are considering something like that.

This isn't to say it'll get to be as complex as portage, but it will probably have to get at least as complex as ports. Which then begs an obvious question...

Yes, we are aware it will get more complex over time, but by keeping minimalism as the #1 goal, let's see how "little complex" can we still be while being reasonably feature-complete for real world usage (and some would even argue we already are).

Re:Easier to Write Build Scripts, Please?

[HishamMuhammad]

If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!

Exactly! That's our #1 design goal. Most of the more active users in our mailing list have already contibuted at least one build script for their favorite app. That's how the recipe-store has grown so fast.

Re:Screw that

[BrookHarty]

We use /appl (/opt in a jam) for all our software. And most production software uses its own /etc, bin,log,lib, directories. /appl/oracle with everything in its own directory.

While this works, I dont care for gentoo's problems with Mozilla and QT3 compiles, you can recompile an application and break 2 others, gets to be a hassle. But you trade the hassle for speed, or ease (I guess)

Sometimes I just want to rpm -ivvh --force --nodeps and forget about it. And to tell the truth, there is alot of misc stuff on linux/bsd/solaris boxes that could be cleaned up. X directories alone are garbage. /usr/X/lib/X11/fonts WTF, I've always hated how X puts files that are not libs in /lib.

And this /share directory, how about a simple /fonts directory for the entire system?

OSX on the other hand is set out clean, they did a good job the personal /home directories. I love how fink is just in /sw for the whole system, and doesnt touch a system file. Even my WinXP box has a cleaner directory structure.

Think Gobolinux might be on to something. I'm gonna install it later and try it out.