A Clean Linux Install? 23
linux_penguin asks: "I've been using Linux for a few years now, and have only just hit the wall I believe most intermediate users hit at some time... I hate RPM and all of its idiosyncracies, and I hate all the clutter and unnecessary junk most distributions install. I wanted to compile Enlightenment from CVS, and it turned into a major hassle due to RPM dependencies and libraries being spread everywhere. What I would like to achieve is an absolute basic install, and then build the system up slowly with source (with most stuff being installed into /usr/local hopefully, leaving the basic install clean and untouched). I know this is a fairly tall order, but has anyone achieved this to any degree and can anyone give me advice? What's the best distro for *this purpose*? Or am I better off building my box from the ground up, to the point of compiling *everything* from source? I would like to use this as a learning experience to gain greater knowledge of Linux and how it works."
the best distro (Score:1)
I hit that wall too. (Score:3)
First thing I did was use Debian, imho it has a better packaging system. But I don't think that will solve your problems.
Though debian does come with a resonable base system (~50megs I think). And if you setup your partitions right, you can install your base system, then mount
However, I don't do that, I just use debian, and when I want to compile something from source, I usually create a
eg:
I also do it totally non root, so that there is no chance of me writting over anything else.
The problem comes if you want to install a package that depends on something you compilied yourself. The packaging system doesn't know you have it. When that comes along, I usually just compile the desired program from source, and it finds the libs it needs.
In the end, if you want to use package management, you really need to use it all of the time, or hassels will develop.
One point though. "Alien" is really handy. Its an app that converts between binary tarballs, rpms, and debs. I use it to convert RPMs to Debs all the time. It seems to work okay.
---
Not hard... (Score:1)
If you want to keep using an RPM based distribution, some hints. First, don't install X or any of it's related stuff. Also don't install anything that you aren't going to need the second you turn on the box (like gcc or make or apache or ftpd or telnet or ssh or basically ANYTHING). All you want are the very basic packages (in RH stuff like basesystem, dev, kernel, bash, util-linux, lilo, etc). And make sure you have a very big
Personally I do clean installs every year or so just to keep this kind of problem from getting too much out of hand: I build a lot of stuff from source and also install a lot of third-party RPMs, so things get crufty fairly quickly. I keep stuff that I download in
The other alternative is to compile a kernel on one machine, make a boot disk, and start totally from scratch, downloading source and building it. Better be a fast machine, though...
Note that the problem is probably not so much a problem with RPM as badly made packages. I've had problems with Redhat stuff before that was caused by bad depenedencies. Though RPMs relocatable package stuff isn't as good as it could be (hmmm... there's another thing to go on the rainy day project list).
linuxfromscratch.org (Score:2)
slackware (Score:1)
slackware doesn't make you worry about breaking dependencies or anything. The flip-side is that if you don't know what you're doing when you, for instance, recompile init, you can really mess up your system.
I'm currently in the process of recompiling everything on this rh 6.1 box. As long as you're reasonably cautious to be nice to whatever package manger is dealing with dependencies, you can customize any distribution.
Zipslack (Score:1)
The downside: it's distributed as a UMSDOS filesystem. This means that you have to find a vfat partition somewhere (a normal one you normally use is OK), unzip the file, and move everything to ext2. Otherwise you will have weird unusuable UMSDOS filenames.
The distribution was designed to fit on and boot from a zip floppy. I needed to install it on a laptop with no CDROM so it went something like this: Installing some 'other' distribution that has net-boot-install capabilities on /dev/hda2, leaving /dev/hda1 an empty partition... make /dev/hda1 big enough since it will be the root partition in the end... boot the laptop... mount the empty /dev/hda1 somwhere... mount the unzipped zipslack-on-zipdrive in another machine (UMSDOS)... put that somewhere ftp-able... ftp the whole thing (or a tarball thereof) into wherever the empty /dev/hda1 is mounted on the laptop... rdev the kernel there to use /dev/hda1 as its root device... change the fstab there to mount as ext2 (otherwise it will be UMSDOS and weird case-sensitivity things will happen)... boot the new kernel, remove the other install from /dev/hda2, and get on with your life.
There is a README with zipslack which details other things, like adding X.
OT: Not Trying To Troll! (Score:2)
This is the exact reason I started to use FreeBSD. I was tired of all of the extra junk and a coworker mentioned that with FreeBSD, I'd have complete control over everything installed and the dependencies and everything would be handled automatically. It's pure magic.
I know this is off the Linux topic, but I really wish the Linux distro people would take notice.
Did this over the weekend. (Score:1)
here's what I've been doing lately (Score:1)
I've been hearing lots of praise for ease of updates and package management from debian users, so you might want to check out debian-- particularily if simplified updating and package management are your motivation. I was also looking for more lightweight initialization scripts that I could more easily modify, so that was another reason for Slackware v. RedHat.
I did a fairly basic install and built up the rest from source. I put most everything under
Note that you will still have to deal with dependencies and libraries-- you just won't have a package manager warning you about it. More than likely you will find out either when your compile from source fails or an app you built fails to work properly. This happens more with development libraries and projects built from cvs (which you mentioned interest in enlightenment from cvs), so expect to have some occassional update cycles there.
One thing that got me recently, though it is not really that big of a deal, was when I upgraded to XFree86-4. I lost some of the older libs that things like Acrobat Reader are looking for, so those no longer run. I don't use it enough for it to matter, but things like that can happen- update one thing, break several others. Of course, had I not installed X into a fresh directory tree, I could have avoided the problem, but I wanted to start clean and didn't mind breaking a few things temporarily.
All in all, it has worked out pretty well for me and my system seems stable. I would also recommend that you keep a copy of the source that you build. I move source directories that I've built to
One thing I did consider was building my install from the ground up-- as you mentioned. Actually I was thinking about starting from a minimal distro like tomsrtbt or trinux. I ultimately had to face the harsh reality that I just didn't have that much time. But you will definitely learn a lot and several people have done that successfully if you decide to try it.
Good Luck,
-Phil
BSD could be the thing for you (Score:1)
What I would like to achieve is an absolute basic install
The install of FreeBSD is ~60M. It includes basic daemons, tools and gcc.
and then build the system up slowly with source (with most stuff being installed into /usr/local hopefully, leaving the basic install clean and untouched).
Everything you compile from the ports collection goes into /usr/local with its own etc, lib, bin and so on. If you wish to get that lean 60M system back after half a year, just remove the directory. Sounds incredible, but it's true. Even extra startup scripts go into /usr/local/etc/rc.d
-Tomek
I hit the same wall (Score:1)
Slackware indeed! (Score:1)
But how many does that?
If you belong to the 99% who just *has* to "fiddle" around you are in for some serious troubles.
Since I switched to Slackware everything have been a breeze... and I can sleep again!
IMO it's by far the easiest dist.
Bjarne
Re:someone otta (Score:1)
For anyone who is not familiar with
Previous Discussion (Score:2)
There was some previous discussion on a similar topic a while back (The Perfect Distribution [slashdot.org]), where many of us had the same lament. The general concensus seemed to be a minimal Slackware [slackware.com].
My advice, if you don't want package managers, would be to avoid RedHat like the plague. Avoid Debian. Use Slackware, or use the Linux From Scratch [linuxfromscratch.com] resources to make your own distribution. This route is guaranteed to make you happy (in the long run, at least), but is significantly more difficult than just installing an "established" distribution.
Freshmeat [freshmeat.net] has had a few editorials [freshmeat.net] on package managers, incidentally, like The Universal Source Package [freshmeat.net], which might be of interest to you.
darren
Cthulhu for President! [cthulhu.org]
I had the same thing (Score:1)
its a great distro(for the poweruser)
Re:RTFM? (Score:2)
The problem with the FM is that not only does it not tell you how to handle interactions between RPM installs and source installs, there is no way to handle it. If I install Perl from source, every other RPM I install complains that the Perl dependency fails, and I have to install with --nodeps. Doesn't that defeat the purpose? Yup, it does.
Most software doesn't come in RPM format, and when it does, it often comes without the required parameters or options. What then?
darren
Cthulhu for President! [cthulhu.org]
One more thing... (Score:1)
Once you get your basic system together and working properly, make a backup copy and a quick and dirty method of re-installing it. That is, a boot floppy with tape/zip drivers, a second/spare disk partition, burn a CD, or whatever. Then you can start fiddling with(aka improving) it without worry.
Take a little extra effort (Score:2)
The increased ability to manage software and keep track of what's there will be worth the added hassle of writing or modifying specs.
Really, I don't understand why everyone hates package managers so much, unless it's because they don't have enough machines to administer. With one machine, it's fine to have a huge mess of binaries, no good means of removing all the files associated with a package, etc. You can stumble along fine, with only a little wasted effort. But when you have more than one machine, the hassle of keeping everything up-to-date makes package managers nearly essential.
Green Frog Linux (Score:1)
One tip, make sure you have a kernel source near by to rebuild to support the network card you have.
http://members.linuxstar t.com/~austin/GreenFrog/index.html [linuxstart.com]
Citrix
Re:Green Frog Linux (Score:1)
Re:Previous Discussion (Score:1)
Agreed....I used to use Slackware when I started, for the very reason you'd be interested it in; it's a base install. The only thing I didn't like about it was it used tgz tarballs for all it's packages, but you could read through /var/sadm to find out what was there.
I recently switched to SuSE, but only becuase I'm ont at school any more with a T1 line at my disposal to downoad packages any time I need them...SuSE has the ability to go the other way...with 6 CD's of software (6.3), I generally don't need to hit the net to download new packages for months after I install a new version, and when I do, it's generally updates or such.
Re:Stampede! (Score:1)
Re:I hit that wall too. (Score:1)
That is, either use precompiled packages (or source packages you compile yourself, not much difference), and learn to create packages out of not-packaged softwares...
More easily said than done, but worth it I guess (you can then distribute your packages, install them on many boxes easily, etc.)