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

WHAT?

[ajutla]

"Does away with" /usr/bin and /lib?


BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!


...In all seriousness, though, that does sound kind of like an interesting concept--might make things easier for people to understand. Me, I like my three letter unpronounceable paths all the same :)

Re:WHAT?

[Anne Thwacks]

Many years ago, in the olden days I thought about this, and was quickly redirected to the "one true path" - it may be marginally more helpful TO ENGLISH SPEAKERS to have meaningful commands, directory names, etc - but unix is multi-user, and supports multiple locales, and the traditional commands, paths may not be meaningful, but can easily be aliased - each user can provide his own names, in his/her own language, but at least the standard ones are standard.

You are welcome to alias them to whatever you want, but it wont help you understand your next door neighbour's Unix system, or your next employer's either.

Uhmm

[NitsujTPU]

But is yet another source-based compilation system needed?

Uhmm... I guess not, from now on, we'll do all of our compilations without source code... however that will supposedly be done.

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?

Re: A job for ln?

[mercan01]

They're trying to replace an arcane directory structure, not mask it.

"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:It works for Gentoo

[XO]

Just because you have a Unixish kernel does not mean you have to have a Unixish operating system.

Surprisingly, not everything in the world has to be Unix!

The shorter the better

[Moth7]

It's much more difficult to make a typo in /etc than /System/Config. That's one of the godsends of the POSIX structure over that of Windows - /lib is easier to remember/type than C:\Windows\System32. And there are none of those annoying spaces in /usr/bin that exist in C:\Program Files.

Re:The shorter the better

[SmilingBoy]

/usr used to stand for "user" in earlier Unix implementations - all "home" directories were under /usr, i.e /usr/joebloggs. A more detailed discussion can be found here.

Screw that

[brunes69]

Blasphemy my ass. i have been using Linux, BSD, nd other UNIX derivatives for over 10 years now, and all I can say is THANK GOD.

The /usr/bin, /etc, /usr/local concept is totally outdated. Having apps in their own directories eases maitenence, eases administration, and eases uninstallation. Think about it, if apps were in their own self contained directories, who even *needs* a package manger? To install, you extract the tar, to uninstall, delete the directory. Boom snap, done and done.

Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.

Re:Screw that

[McDutchie]

Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.

Except that many applications install their own DLL cruft under C:\WINDOWS anyway (Microsoft itself being one of the worst offenders), and that the program stops working if you move the application dir around, thus eliminating completely the usefulness of this concept.

No, the OS that does this right is Mac OS X. Installing an app is as simple as copying the application package (basically just a directory), and you can put and move it anywhere.

Re:Screw that

[stevey]

And that's exactly what scripts such as GNU Stow do.

The 'foo' application is installed in '/usr/local/foo-v1.x', and symlinks are placed into /usr/local/bin so that it can be run.

This makes installation and removing applications simple - and you can share your applications across NFS if you're so inclined.

"Recipes" are a bad idea

[RovingSlug]

Knowledge for handling common situations is usually added to Compile itself instead of being coded in the script ... It remains to be seen whether this experiment of gauging differently the tradeoff between flexibility and simplicity

Yes, simplicity is good, but only in the context of the whole system. Here, you're just shifting complexity from the per-package scripts to the overall Compile package itself -- creating a large, central, monolithic service.

Because it's centralized, over time, this is going to accumulate a lot crap and become opaque, obfuscated, and unmaintainable. Changes and maintenance to Compile will more significantly impact the contemporary set of recipes than, say, changes to Portage and ebuilds.

It's easy to apply a good idea, like "simplicity", in too narrow of a scope -- to the detrement of the overall design. Better to think about it as balance of "package maintainability", "system maintainability", "barrier of entry", etc.

Re:Non-issue

[Jameth]

Yeah, but who the hell starts them with capital letters?!?!?!

Even with tab-completion, I just got my time quadrupled! Frickin' shift keys.

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:Sounds like Mac OS X

[HishamMuhammad]

To be fair, this isn't even a new idea for Mac OS X. It came from NeXT.

Re:All I want is SATA RAID support

[Nasarius]

Debian and Gentoo are the only ones, AFAIK, that do, and they both are teh suck.

Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)

Re:Non-issue

[HishamMuhammad]

Every modern shell supports case-insensitive tab-completion. And in GoboLinux, this is enabled by default.

Try it, you might like it: on bash, just add

set-completion-ignore-case on

on your ~/.inputrc.

Re:Non-issue

[vadim_t]

There is plenty.

There are several languages where lowercase -> uppercase -> lowercase can't be done without losing data, for example. Then there is the problem of how many languages you can support. Say, English is easy, but what happens when you find a disk with filenames in an encoding the filesystem doesn't know about?

In Linux, it's just all bytes, it doesn't care if it's english, cyrillic or whatever. With case insensitivity it suddenly has to know what to do with cyrillic letters as well.

Re:Unix paths

[sirReal.83.]

And no, OSX is not LSB compliant - go figure.
This might be nitpicking, but I think you didn't read what the first letter in 'LSB' stands for - Linux :)