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."
I would tend to agree that breaking the paths would be bad, fourtunately they don't exactly do that.
/Programs/Xorg/6.7.0 and /Programs/KDE/3.2.2. Each file category (executables, libraries, headers) can also be accessed through unified symlink views, such as /System/Links/Libraries and /System/Links/Headers. These views match the legacy directories (/bin, /usr/include, /usr/local/share) and so on, achieving total Unix compatibility while keeping program directories completely self-contained."
What they do is provide a more intuitive (on the surface of it, it seems so to me, need more details to be shure) path system while maintaining compatability to the old system.
"In GoboLinux, each program resides in its own directory, such as
They claim thier systems is path agnostic.
this is a good thing imho. One of my (minor) pet peves is that the standard *nix path system is largely cryptic to joe user, and a pain in the butt even for the cluefull unless you have enough *nix experience to make it automatic.
Now if they fix cut and paste and find a way to make havening both a *nix and a windows version as close as possible to a simple recompile with a few options/flags changed the year of linux as a major desktop contender will finally arive istead of forever being next year.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
Actually, GoboLinux works thanks to symlinks, but the other way around. /etc is a symlink to /System/Settings, in order to maintain good Unix compatibility.
/System/Settings is the "global view" of every apps' settings (ie, /etc).
Each app has its own Settings directory, and
The filesystem is the package manager
a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead
For all those thinking "what a nice idea":
afaik LSB requires FHS which, in turn, requires the standard directory structure. Does this mean we should throw the whole LSB out now?
And no, OSX is not LSB compliant - go figure.
I've recently switched from linux to OSX, and I've learned that the latter has some clever ideas (e.g. bundles) that can leverage developer effort. Given this context of learning by changing, my own view is that this new direction for linux is worth investigating ... not that I'll likely leave OSX anytime soon.
This is similar to the evolution from ant to maven for Java developers. With ant, you gave the steps necessary to build your system, an imperative approach. With maven, you instead describe the shape of your system, and it figures out the steps.
;)
Projects become more uniform as a result, and developers spend more time building the projects instead of maintaining build systems.
My only concern is the knowledge or experience that's lost as a result; larger and larger groups of developers have a smaller and a smaller understanding of the tools, environment, and subtle filesystem dependencies that systems tend to have, putting the experience in in-the-field debugging into a relative tiny number of cutting edge high-priced consultants.
By the way, I'm available.
To be fair, this isn't even a new idea for Mac OS X. It came from NeXT.
The filesystem is the package manager
With the simplistic file paths, and with a pretty decent amount of packages already, this is the distro that I might share with my friends. Especially since it's a Live CD.
After I get home from work, I'll download it & give it a spin, that's for sure.
Even if some might consider this a "dumbed down distro", this idea makes me thing that it could be one for tha masses.
Time will tell.
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
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.
sort of but not really, NeXT's filesystem had a difference in philosophy, this has a difference in naming conventions...
/stuff/include/foo /stuff/lib/libfoo.so
/stuff/foo/include /stuff/foo/lib/libfoo.so
where in typical unix naming conventions (because i'm lazy) you'd have something like
you'd end up with something like
different implementations of the same filesystem philosophy, like things go in like places...
imho the philosophy is what needs changing this seems like just a capitolized and descriptive maze
tho i've never used it so i can't really say.
Rox Desktop / Filer (GTK) does this for Linux, and the filer app (sort of Nautilus replacement) is blindingly fast too.
Scroll down to "Applications are directories"
If you're confused about how the directory hierarchy in a typical Unix-ish system should be setup, consult man hier, or if your distro failed to include that, see this hier man page.
And the muscular cyborg German dudes dance with sexy French Canadians
An autoconf recipe can be created with a simple "MakeRecipe http://dl.sf.net/foo/foo-1.0.tar.gz". In many ways creating a Compile recipe is easier than compiling by hand.
Yes, I basically agree with you. The Armagetron recipe shows the "ugly" side of recipes: the support for imperative constructs, which often slip in declarative systems (ask any functional programmer...).
:) What we're doing here is just trying a different approach. Time will tell if it produces revolutionary results. :)
In this particular example, I think the recipe author could have avoided the pre_build function using a patch instead. I recommend that very strongly to users, because patches are easier to maintain when writing a new recipe based on a existing one: patches make "rejects" when they change from one version to another, whereas that sed command will fail silently if the recipe writer is not careful. With a patch instead of the function, the Armagetron recipe would be reduced to 3 declarations.
But yeah, there are cases when ugly imperative functions will be impossible to avoid. This most likely means that the design of the project's build system is pretty screwed up.
What I, personally, try to do in those cases is, instead of writing a marvelously smart recipe, is to contribute a patch to the project itself. Most of the times, it's just $prefix-awareness missing, or something like that. Often the effort people spend working around build inflexibilities in distro-specific scripts would be much better spent improving the programs themselves.
It's usually less work to "fix the program" than work around it. For a few key packages for GoboLinux I even contributed the autoconf scripts, and it was way less work than I thought it'd be. The one thing I like about this approach is that it helps the entire free software community, making for smaller recipes, smaller ebuilds, smaller specs, and so on.
Sure, it ain't revolutionary today, but revolutions don't happen from night to day... they are secretly planned for a long time before the strike.
The filesystem is the package manager
/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.
ahem.
/usr/local and /usr, /bin and /sbin - try to understand what they are, and if you do any admin work above your desktop machine, you might agree they make good sense.
read the FHS, then come back.
now, realize that while you can critisize what you don't understand, you come off looking about 14.
there are reasons for
You should look at rox which advocates and uses an appdir apporach in unices (which is actually really neat and effective, they even provide ROX-LIB which shows how it would work with repect to libraries.
True, libraries would still have to be in some common area, but at least would have all relevant resources entirely contained in a subdirectory.
OSX does some impure global resources stuff and some things (particularly Apple packages) are installer based and contribute to tossing things all over the place...
XML is like violence. If it doesn't solve the problem, use more.
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.
.NET fixes this problem by deprecating use of the registry, preferring systemwide configuration for an application to be in the application's directory, and side-by-side DLL use. They even market the whole idea as enabling "XCOPY Deployment" (referring to the DOS utility XCOPY, which can copy a whole directory tree).
The only shared aspect it has is the GAC, which is really only intended to be used in special cases, not in a general application's use.
NO CARRIER