Skip to main content
Welcome guest. | Register | Login | Post

LFS and the Hurd

I'm currently trying out LFS again. I'm using BLAG (basically FC5) as the base, and I'm reminded once again at how slow doing things with source is. I hear people complain about how slow YUM is, but compared with using source AND using all the test kits it is extremely fast. In a few days I should have quite a nice little LFS system, which I'll make sure is Free. With any luck I'll also be able to run CVS GNOME on it too as well as other mad things.

The thing I'm not looking forward too with the LFS is keeping packages updated. So I'll have to find a decent way of recording which software I have installed and which versions they are, and then finding out when the latest versions change so I can update my software base. I fear I'll have to hack together some weird scripts for this, but we'll see.

I'm also thinking about giving the Hurd a go via the Debian GNU/Hurd project. I think it'll be an experience trying to get the system to work as GNU/Linux now works, and may lead me to post bug patches etc. to help with the project. I look forward to the day there is the GNU operating system - kernel and all.


You could try using CVS

You could try using CVS versions of everything, so you won't have to pay attention to version numbers. (I know this idea is insane)

It's probably a good idea to use a package manager. Or you could write your own package manager. I would do that before starting to build LFS.

If you update regularly, you should use ccache to decrease the amount of time needed for recompiling the files that haven't been changed.

For my LFS-project


For my LFS-project (automatian via a couple of scripts, mentioned in somewhere here on Nuxified before) I already wrote a big bunch of scripts (I made it pretty modular, so you got more or less a script per package) and I also compiled a list of used programs/libraries including the URL where to get the stuff.
If you like I could post that document here, you would just need to find a way how to find out the latest version on the server (which I also still need to do) in order to write a nice little update-script. A problem here might be low-level stuff, like GLibC. I already experienced a total system failure after upgrading this (I shouldn't forget to mention this was on Suse 6.2), but for most other stuff it should be pretty safe.

@tibutenh Running

Running everything from CVS would be quite radical and I'll investigate the idea with programs which are not linked to the toolchain and basic system functionaity.

Your scripts sound interesting and useful, I'll hold off asking too see them for the time being as I'd like to learn how to 'do it myslef'. I'll look into ways of getting the latest package versions too and let you know if I find a way.

I wonder if you could mix

I wonder if you could mix the hurd vanilla kernel with LFS..

A way

AndrewB wrote:

I wonder if you could mix the hurd vanilla kernel with LFS..

I'm sure there is a way, though since GLibC is linked into the linux header files I think it would not be easy.

You might search for new

You might search for new versions by letting your script check freshmeat pages.

I've started coding

I've started coding something up. The script currently checks what the latest version of the package is against a file, downloads a webpage which lists the package tarballs (e.g. ). I only have this part working for GNU packages so far. It then uses grep, sed, awk and tr to get the links to the package out. It then finds out the latest version available and compares this to the one found on the system, if they differ the package will be downloaded.

Things I have still to work on:
Using gpg to verify downloaded packages.
Do something with the package once it's downloaded.
Make the script more modular, with better use of functions.

I'll post some code once I'm happy with the current state of the script.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.