So, I'm slowly working through putting together a LFS system and once completed I plan on starting on BLFS and start using some sort of package management system. I've read the hints page where people have successfully gotten Debian and RHEL package managers installed but none are recent ( <= 6.3) so I'm not sure if they're still valid.

So, is anyone using any package manager for their LFS system and if so what's your experience with it? (i.e. installing desktops like GNOME or KDE and browsers like Chrome) I'm just interested in hearing people's experiences as I'm deciding whether or not in the long term it'd be "easier" to use a distro more like Arch or Gentoo.

Thanks guys

I'm not sure if this is more appropriate for the general forum but feel free to move it if it belongs in there

I have used pretty much everything out there at one point or another.

I did an LFS years ago. I did get the Debian package manager working, it was a headache!

Here are some of the things I have observed over the years (and not bashing and distro here, it is about choice):

LFS is to learn, if you want the headaches of being your own maintainer of everything, have at it!
Gentoo and the like become tedious. You get the control and you become obsessed with it and things can and will break
Debian and derivatives make me scratch my head. You want package X but the maintainers decided to include package Y as a dependency, you have no interest in Y but cannot remove it because it will remove X even though X might not need it.

I do use Arch. Why? Because it is flexible and very vanilla. dependencies are just what the package developers have as needed. It is fast, it is everything I want/need and nothing more, it rolls so no re-install ever X months...

Time and research equal knowledge, what you will learn doing LFS is very valuable. Time also equals money (in a sense) and the investment to maintain a system like LFS or Gentoo is just not worth it IMHO. YMMV

I still have my LFS installation, ready and waiting to boot any time I want it to, resplendant with xfce, xchat, firefox, thunderbird etc all built from sources (yes, even firefox and thunderbird) and I'll keep it around a little while for two reasons:

i. It's nice to occasionally boot into an OS that's "Made by me!"
ii. Apart from the learning aspect, I built it for a purpose, and that is to build a particular program (that has never been built for a pure 64 bit system) in an environment that I know is completely untainted by and 32 bit libs etc. (something I haven't managed to achieve yet).

Would I keep it around longer than that and try to maintain it. The simple answer is "probably not". Whilst I enjoy the tinkering, the fixing and the building, I want to do more with my system. Maintaining and updating an LFS system could become a full time job.

Like corbinboy, I've been looking at each of Arch and Gentoo for my next system (currently I'm running my main OS from a Debian base) and I will probably settle on Arch for exactly the same reasons that he's already covered.

I was using a custom set of pkgtools (the Slackware package system)
They are so simple:
when you do "make install", di "make install DESTDIR=/foo" where foo is a temporary directory
cd /foo
Make all the modifications like mv /usr/lib/* /lib et similia inside this dir
makepkg -l y -c n -s y ../foopackage-1.0-i686-1.txz (it make your package)
installpkg foopackage-1.0-i686-1.txz (install your package)

That's all.

I use a modified version of the package-user system by Matthias Benkmann. I find this extremely useful because it lets you see exactly what the package is installing and what it is trying to do to your files.

Take a package like cups. The Makefiles are horrible in the way they are written. They try to change the permissions of some of the high level files on your system, such as /usr/bin and /usr/lib and many others. You may not mind this but if you install as root, you'll probably never know exactly what cups has done. With the package management system cups cannot change permissions and so will stop. You have to edit the Makefiles to remove statements like $(INSTALL_DIR) -m 755 $(MANDIR)/man1. Putting a statement like this in the Makefile is a disgrace and the author should know better!

So if you want complete control over what is being installed on your system, use package management. If you don't mind packages trampling over your installed files, use something else.

jb.

this is the other post.

so i can use urls in my next one 8) muahaha

sorry for this 8)

m.

---------- Post added 12-09-11 at 07:04 AM ----------

hi..

we are using a LFS based Distribution for some years now in a production environment.. Last year i started to completly rebuild our system from scratch based on on the latest LFS at this time..

in our first approach we used a very complicated package-tracking (i won't call it management) system where we scanned the system, installed a package, scanned the system again and the resulting diff of the two scans was the content of the package.. easy, not very fast, but it worked..
but it was ugly as hell and all the information how a package was built was lost somewhere in the depth of our filesystems.. it was hard to rebuild/update a package..

so i looked at the tasks we have to do in a very trivial loop... get the source, extract, configure, build, install, package.. all package-management software out there like rpm/deb/pkgtools/ehatever was to complicated and to powerfull.. we just want to build a software, install and remove ist.. no complicated dependency checking, repository choosing, complicated syntax learning will help us do the job.. 8)

so we started a small pkg-builder with minimalistic package-management features based on our tools we used in the past..
since wget, tar, ./configure, make, make install.. are all we need to build an LFS system we decided to just build a bash-skeletonm for our packages were all the information how to build the package is included and documented.. this skeleton can be used to rebuild and update the package..

after some heavy optimization we ended up with a software we call bee "Bau Et Einfach"(german) which can be translated to "just build it"..
were we create a generic build-file (the bee-file) which in its easiest representation has exactly 2 lines..

a first line to specify the interpreter - a bash script which just exports a bunch of functions and variables and starts the build..
and a second line to set a variable where to get the sources from -> the url of the realease tarball..
e.g.: SRCURL[0] = "http://wherev.er/whatever.tar.gz"

this 2 line bee-file then can build a standard package from a release tarball just by executing it... the name of the resulting package is based on the name of the bee-file..

since LFS is based on various additional options/hacks which are included in the build process there is of course a way to include all those hacks in the bee-file..

after executing the bee-file you end up with an installable package.. (bee install)..

behind the scenes: bee just uses the default build processes and features like DESTDIR= to install everything temporarly in some image directory..
and then packages the installed files along with some meta files to a standard tarpackage... which can be extracted manually or installed using bee..

how easy it can be(e): we even implemented some intelligence in extracting version information so that we can build generiv bee-files for a specific software so that we can update a software by just renaming the corresponding bee-file and executing it under the new name (as long as the build process did not change dramatically):

e.g. cp bee-0.3-0.bee bee-1.0-0.bee && ./bee-1.0-0.bee && bee install bee-1.0-0 && bee remove bee-0.3.0.x86_64

to create a bee-file skeleton is as easy as: bee init https://github.com/mariux/bee/tarball/bee-1.0_rc20

it is not yet released, it lacks documentation, it may have bugs, but we are currently using it on our production system, which is based on LFS and features everything from linux kernel to GNOME3/KDE4/XFCE4 with firefox and libreoffice (oh yeah.. we actually don't had the time to compile libreoffice.. but we used bee to install the official rpm-based libreoffice release) and even KVM and other cool stuff we are currently working on..

since this is open source you can track our current development process here:
https://github.com/mariux/bee

a prove of concept on how to build LFS with bee: which is still pretty empty 8)
https://github.com/mariux/bee-lfs/tree/mariux

requirements are (uncomfirmed and incomplete)
bash4
perl5

feature:
- LFS inspired build tool
- supports: autotools, cmake, (pure) Makefile, perl-modules, python-modules ..
- easy, automated patching by giving patches in a list of URLS/absolut pathes/mix..
- build process can be easily manipulated using bash syntax and every tool you like..
- generated packages can be cleanly installed/removed at any time..
- NO dependency checking/support..
- NO real package management..
- NO external Repositories..
- some generic install time hooks to update mandb, ldconfig, etc..
- THIS IS NOT A REPLACEMENT FOR ANY PACKAGE MANAGEMENT OUT THERE...
it is just a helper.. to easily maintain a lfs based distro 8)
- bee-file, metadata, pacthes are included in the resulting package to allow an easy
rebuild and to maintain the documentation of how a software was built..

may be some one wants to give it a try when 1.0 is released..

install is just: get it, extract it, make , make install ...

usage: bee init <URL> ; edit and execute the bee-file created (./software-1.0-0.bee) ; bee install software-1.0-0 ; start the software ; "bee" happy 8)

if you like it.. contact us... if you don't like it.... just ignore it... 8) please don't start flaming till the first official release is out.. 8)

marius tolzmann & the bee people.. 8)