Hi all, This is certainly going to not be 100 % on-topic, but I see no better place to put it. It will also be long.
Ever since I read "Der Unix-Werkzeugkasten" (most likely the German translation of "The Unix Programming Environment") by Kernighan/Pike, I wanted to have my own Unix machine. And with my trusty Amiga slowly becoming obsolete and Linux picking up momentum, I finally bite the bullet and bought myself an (until then frowned upon) x86 PC. I also bought a cheap SuSE Linux distribution (kernel 1.0.x). And was happy. Every few months, SuSE offered a new set of CDs, which I bought in alteration with a colleague. But then SuSE become more "professional". The distribution adopted Red Hat's RPM package management. Trying to install a Linux system just like I wanted it became a nightmare. The packet selection was sluggish, and there was virtually no way to satisfy the dependency checker. It didn't take long until I hated RPM. The whole system more and more appeared to me convoluted and strange. You were no longer allowed to edit configuration files, this had to be done by yast (which I remember as a real PITA; todays yast is definitely no longer so). And I couldn't just download and compile programs I liked without wrecking the package management. I yearned for something where I had total control. So I tried building my own Linux from scratch and failed utterly. A few months later, I stumbled upon LFS, and immediately recognized that this was exactly what I was looking for. At last I was able to do what I wanted, thanks to some great guys who had figured how to bootstrap a system. I don't remember the exact date or version, but IIRC it was 3.0 or something like that. Anyway, ever since then, my system is running LFS. By that time I also inherited the job as system administrator (for machines that smelled like Unix) at my job (only part time, though). When the (SuSE) distribution on our 4 Linux workstations became dated, I replaced it with---you guessed it---an LFS/BLFS system. But even I had to realize that some basic kind of package management was a real necessity. Something that kept a log of what file was installed by what program looked like the perfect minimalistic answer to me. 'git' (Guarded Installation Tool) promised to do just that. Which it did. Still, it left something to be desired. I usually installed something in the background while doing other work. And installations failed. Often exactly in the 'make install' phase. I forgot that an installation was in progress and started another one. And git's "find /usr /opt ..." took ages and occupied my hard disks. Whatever, the whole system slowly became a mess. More or less constantly building new LFS systems, cutting and pasting looked ever less exiting as a method of building. I read the package management hint (again), and there was one point that really ingrained itself in my brain: the files must not be installed directly into the "live" filesystem, but into a fake one. There they can trivially be listed, patched, whatever. And if the "make install" fails, the system is not affected at all (anyone had a failed update of a vital package?). Now, just pack it up into a tarball and unpack that in the root filesystem. That way, you can even replace programs currently in use. And by leaving the tarball around, you can always reinstall files that get accidentally damaged or deleted, or the whole package. No worries. Clearly, this was the way to go. And since I switched my shell from csh to a standard sh at that time, I decided to write my own package manager as a bash script. That should help learning it quickly. ;-) So I started writing what later got the name 'jim' and building a new LFS with it (what else). It took umpteen tries until it worked half-way. But I learned a lot. And it left me with several points I would love if LFS, but more so, BLFS could address: I'd like to see a paragraph dealing with installation into a DESTDIR. A lot of packages support this out of the box and deal with the details. Others drive you nuts. It took me several hours to get tetex running that way. Dependencies. Figuring out the order in which to build things can be hard. There are required, recommended and optional prerequisites. I wrote a program to give me a build order for a "build everything" that took into account required/optional (I lumped recommended together with required), hoping cyclic dependencies could more easily be broken be the optional link. There were still a lot of cycles. I've abandoned it now. What do you do about this? Build a program twice? Some hints would be greatly appreciated. "make -j" Now that dual- or even quad-core machines become standard, you want to allow make to build a package in parallel. However, with several packages this doesn't work. And the error messages usually don't give any clue that this was the problem. It would be nice if that fact was shown in a BLFS description. All the other programs. BLFS has a lot to offer, but there's so many other programs out there. There are even a lot of optional dependencies in BLFS that have no own description. I understand that it certainly cannot describe every package under the sun, even less keep them up to date. But not all of these others are easily built, and I would so love being able to have BLFS also as a repository of contributed build descriptions. (Like to build FooBar? Ah, someone alread did - only a sed required.) Maybe the wiki was meant for this, but I think it lacks a template that makes it easy to do. Anyone still with me? I warned you it would get long, didn't I? Finally, here's some things I learned to loathe, during my crash course in automating an installation: Installers. They may be nice for a novice, but if you want to build a system over night ot in the background, they're a real PITA. And they usually do not allow you to install into a DESTDIR. It cost me several hours to get the nvidia drivers installed the way I wanted them. Registries. No problem if they can be rebuilt from scratch after adding something that needs to get an entry, like /usr/share/info/dir. But when I look at docbook's 'install-catalog' ... "install -o user -g group" The DESTDIR approach allows "make install" to be done by an ordinary user (a benefit you don't want to lose!). Using "root only" commands in Makefiles breaks this (chown are much easier to catch and "replay" just before creating the tarball). In the past years, I did, of course, try "real" distributions now and the. Ubuntu, Fedora Core, Debian, Opensuse. While all appear rather nice, none of them really appealed to me. Now, after spending half of my day off with writing this and annoying all of you, it's time to fall back to "mostly lurking" mode. I'm not a BLFS developer, I have contributed almost nil, so I can not make any demands. In case this diatribe might make it look differently: I am forever grateful for LFS/BLFS and I owe all of you. I did not mean to critize the project or anyone involved. Regards, Hans-Joachim -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
