[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
I have long had a problem with RPMs, since they are built for a particular architecture in mind. I don't just mean the hardware, but the operating system structure as well. I don't like the way that I have to install X and Y just to install Z, and that RPM dependencies are tied to particular versions of other RPMs. Just a gripe, and I may be wrong these days with RPM v3, but I left that all behind a long time ago... I have, for the past 7 months, been working on building my own GNU/Linux distribution. It started off as a lowly installation, but now I have grander ideas of world domination, et al. The difference between my installation and an RPM based installation (or any other managed package system, for that matter) is that my packages are compiled *by* my machine *for* my machine. That's ALL packages. Not just the kernel. During build time, I can optimise each package for my processor. I can also select exactly what I want installed, down to individual binaries, if necessary. Three reasons why I did this: For one, the difference in speed is noticeable. For two, I know what everything does, and why it is there. For three, I know how my system is configured, from the bottom up. I must say I am very pleased with my installation. I works the way I want it, and if I want to change, add or take away, I can. The base installation is derived from Linux From Scratch (LFS) (see http://www.linuxfromscratch.org), and I have added a number of additional packages, including XFree86 and KDE. To be honest, installing a GNU/Linux system from sources is easier than it sounds. A *lot* easier. I would recommend anyone to have a go. All you need to understand is what the following means: % ./configure && make && make install And if you don't, you want to read at least two man pages! I am currently working on building an installer that will assist a 3rd party (if not myself!) in installing and configuring GNU/Linux from source packages. I am also working out how to use the same approach to build a firewall (spurred on by Simon...) and could equally apply the process to any amount of target installations. Once I have sorted out the details, of course. :-) There is an automation project underway for LFS, called Automated LFS (ALFS). I was hoping that this would produce some fruit, but they seem to be missing the point in some areas. The original project seems to have been hijacked by one or two individuals, who don't really want to listen to reason. If anyone is interested in contributing, let me know... Cheers, Matthew "Paul Sutton" <psutton@xxxxxxxxxxx> on 26/05/2001 22:09:06 Please respond to list@xxxxxxxxxxxx To: "D&C LUG" <Lug-list@xxxxxxxxxxxxxxxxxxx> cc: (bcc: Matthew Gibbons/PLY/Global) Subject: [LUG] K6/2 porting Hi After compiling my kernel to K6/2 native I was thinking of doing the same to the rest of the software, probably using rpm as I think I can recompile the packages to make them k6/2 native then reinstall or upgrade them, this should make my system alot faster. espcially X. I still need to do some reading of Maximum RPM but does anyone in the group know of a similar project which I could get involved with. as i have a cd writer I can then burn the new rpms to cd. I will try and post notes on to my web site to help others. >From what I have found out so far I would need to edit the rpmrc file and change build arch from i386 to k6 or something (k6 because when I copiled my kernel I had -k6 flash up as part of the output messages). However I am not 100% sure on things here, I currently use RHL 7.1 with the 2.4.2 kernel, on a AMD K6/2 with 128mb of ram. thanks paul -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe. -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.