Welcome to the most active Linux Forum on the web.
Go Back > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Linux From Scratch This Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.


  Search this Thread
Old 11-26-2011, 11:09 PM   #1
Registered: Nov 2011
Location: Australia
Distribution: Arch, LFS
Posts: 171

Rep: Reputation: 38
LFS - Package Management Experiences

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
Old 11-27-2011, 03:00 AM   #2
Registered: Sep 2003
Location: Kentucky
Posts: 480
Blog Entries: 1

Rep: Reputation: 51
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

Last edited by corbintechboy; 11-27-2011 at 03:04 AM.
Old 11-27-2011, 07:05 AM   #3
Registered: Oct 2011
Location: Warrington, UK
Distribution: Arch local, Debian on VPS, several RPIs.
Posts: 300
Blog Entries: 1

Rep: Reputation: 55
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.

Last edited by Roken; 11-27-2011 at 07:06 AM.
Old 11-27-2011, 01:57 PM   #4
Registered: Sep 2010
Location: Turin (Italy)
Distribution: Slackware 14.2
Posts: 51

Rep: Reputation: 4
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.
Old 12-07-2011, 11:58 AM   #5
Registered: May 2004
Distribution: FC3
Posts: 87

Rep: Reputation: 27
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.

Old 12-09-2011, 06:04 AM   #6
LQ Newbie
Registered: Dec 2011
Location: Berlin
Distribution: mariux64 LFS based
Posts: 1

Rep: Reputation: Disabled
this is the other post.

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

sorry for this 8)


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


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] = ""

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

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:

a prove of concept on how to build LFS with bee: which is still pretty empty 8)

requirements are (uncomfirmed and incomplete)

- 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..
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)


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
deb package management on lfs r£vilo Linux From Scratch 5 10-06-2006 06:55 PM
Has anyone tried to use package management conary to build LFS? jery_wang2002 Linux From Scratch 1 05-31-2005 06:30 PM
LFS and package management michaely Linux From Scratch 7 07-02-2004 12:57 AM
LFS package management aes12 Linux From Scratch 4 05-09-2003 09:46 AM
Package management in LFS CragStar Linux From Scratch 7 11-04-2002 02:58 AM > Forums > Linux Forums > Linux - Distributions > Linux From Scratch

All times are GMT -5. The time now is 07:22 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration