Linux From Scratch

Re: BSD License?
I won't argue for either license ... however, it's quite unclear what the BSD license applies to [from the FM description], so when I saw it the first time my thoughts were `WTF? How anyone can think she can relicense glibc, gcc, etc. under the original BSD license?'

Re: No package management

>
>
> I do what you suggest, but don't like
> the idea of running find 2 times, so I
> install with another prefix (for
> example, glibc uses make install
> install_root=/root/glibc), do a find at
> /root/glibc, and start moving
> /root/glibc with mc. But I rarely make a
> log, my mind is better than package
> managers and make uninstall.

I used to do that, install every package in

/usr/ and leave the package there.

This made for excellent removal: rm -r /usr/x

and the package was gone. After a while my

/usr partition had a few hundred subdirectories

which wasn't a bad thing, but my $PATH

variable grew immensely. And once you install

a package somewhere moving it elsewhere is not

always recommended as some packages hard-code

certain paths (to say config.files) to the place

where you have installed them.

Right now I install everything under /usr and use

the 'find' tecnique described earlier. I have most

of that processs scripted so I don't have to run

find twice or create diff outputs myself. I run one

command with the parameter (the package name

and version) and it does the find, configure and

install. I run a ./configure --help manually to see

if I need any special configure options (which I

then pass so that script) or other options. It's

primitive and simple but effective. The result is

I have a bunch of files now, one for every package,

that list every single file that was installed by that

particular package. It can be expanded to include

files that were changed, removed, etc.

Yes, this script is based on what Jesse Tie Ten Quee

came up with and I just expanded on it to automate

it a little bit

Anyways, to make a long story short: the point is

that I love the way things work now PM wise. That's

one of the beauties of LFS. I get to pick the

software I wish to use for something.

Re: No package management

>
>
> I do what you suggest, but don't like
> the idea of running find 2 times, so I
> install with another prefix (for
> example, glibc uses make install
> install_root=/root/glibc), do a find at
> /root/glibc, and start moving
> /root/glibc with mc. But I rarely make a
> log, my mind is better than package
> managers and make uninstall.

The point of running two find's is one before and one after the 'make install' (and whatever else commands that install files) so you can have a list of files that get installed, with that list, using standard command-line tools you can created backups, tarballs/packages, uninstall, etcetc..

But i agree, your head is the best thing..allthough in certain cases when you have ~10 boxes to look after and they are all running different versions it's nice to have *some* means ot PM, even if it so "primitive" (hey it works, 'nuff said ;)

Re: No package management

I do what you suggest, but don't like the idea of running find 2 times, so I install with another prefix (for example, glibc uses make install install_root=/root/glibc), do a find at /root/glibc, and start moving /root/glibc with mc. But I rarely make a log, my mind is better than package managers and make uninstall.

Re: No package management
Hmm... I used the LFS instructions precisely because package "management" makes it really painful to upgrade core system components, especially if you don't care for the compilation options used by the existing distributions or you apply a lot of custom patches. RPM just creates a tangled mess of dependencies. Mind you, I use RPM, but just for non-essential stuff I can conveniently rip out and reinstall if I need to. I certainly don't trust a tool as crude and unintelligent as RPM with my core system, especially not in a production environment. It's too easy to trash things and too hard to clean up after.