A while back, I got the wild idea to port the basic
BSD command-line utils to Linux.
It was mainly a "for-fun" project, but I decided to set up a home for the project on
Sourceforge. While I've let the project die a quiet death, I got one response to the project that
intrigues me. It's about a project called Linuxports.
What is Linuxports?
Linuxports is a set of utilities and Makefiles designed to mimic the build process of FreeBSD.
The name is meant to be reminiscent of the FreeBSD Ports section, mostly software ported from Linux and put into a build tree.
While I'm not a FreeBSD user, I grew intrigued with the BSD build process when doing my own hacking. Linuxports is too
early in development to be very useful to anyone yet, but ideally, you should be able to build a complete system just by
doing the following:
And if anything fails, and you just want to try to build what didn't build OK the first time:
Why would you want this?
I really don't think this is the system for everyone. However, there are some of us who like to have loads of control
over their systems, but wouldn't mind an easier way of doing it. To someone like me, this has a strange appeal.
Provided this project follows the FreeBSD model, you could periodically download patches to your local source using cvsup
or whatever tool the Linuxports team chooses to use (I see reference to cvs patching in one of the Makefiles.)
Also, provided they follow the BSD model to the letter, the system shouldn't need to use configure scripts. For those
who don't know what a configure script is, it's a program that can check to see if you have everything installed on your
system that's necessary to compile a given program.
Whereas configure (the GNU preferred method) assumes you could
be randomly installing on any random, nonstandard UNIX variant, the BSD Makefile hierarchy assumes you have a system
that conforms to standards. It looks like the Linuxports team
wants to create a more robust build system than BSD's (for instance, you could go into a particular program's directory and
issue a 'make install'.
What are the potential advantages?
There's the potential, if Linux distributions were to adopt this as a standard, of Linux distributions becoming
more standardized. More standardization is good, in my eyes. It's getting difficult for me (and others) to help someone
set up a Linux box, because distributions are starting to diverge rapidly. If distributions were to adopt a standard
based on this work (once it's further along) it would hopefully bring distributions closer in step, and help strengthen
the Linux community.
What are the potential disadvantages?
There's the potential of not being able to choose what software, and what versions, you want to choose without
doing some hardcore editing of the Makcfiles. It seems to be possible, but not very easy. People who come
from a Red Hat or Debian background probably won't find that very appealing. Certainly, someone who comes from
a non-developer Macintosh backgound will hate the idea.
Hopefully, there will be some sort of mechanism to include/exclude software other than hardcore Makefile editing.
Some people may also be turned off by the potential of a rigidly-controlled
filesystem layout. To those people, I would suggest looking elsewhere.
And, of course, there are the naysayers who will state that this is definitely not the way to convert people over from Windows and Macintosh. Oh well.
It's not really for the converts.
How far along is it?
I'm still waiting for download_world to finish downloading. :-) I'm not sure, but I did happen to catch a line that said,
"You managed to make it this far?" That, and the author states in the README, "If you want everything to fail for sure,
try running make download-world." Not a good sign. However, every project has to have an early, rocky beginning.
So, fellow reader, what do you think? Is this something worthwile? Earthshaking? Bad idea?