Slashdot Mirror
GoboLinux Compile -- A Scalable Portage?
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."
"Does away with" /usr/bin and /lib?
...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 :)
BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!
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.
mkdir /System/Settings
ln -s /etc/X11/ /System/Settings/X11
Couldn't this also work?
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.
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.
/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.
The
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.
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.
Yeah, but who the hell starts them with capital letters?!?!?!
Even with tab-completion, I just got my time quadrupled! Frickin' shift keys.
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.
The filesystem is the package manager