When it is the right time to try to implement a package manager?
Linux From ScratchThis 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.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
If I was going this route, I'd handle it something like this:
Build LFS base.
Build the packager dependencies.
Build the package manager.
Boot from a LiveCD and tarball /
You then have your base dependencies, build tools are in place and a functional kernel. This is basically how Gentoo does it with their Stage 3 tarball.
After this you can try to decouple and isolate some of the earlier packages, which might work with anything that you can rebuild in place like Grub or Sysklogd. But, I don't think you can get much lower than this. For instance, I don't think it's possible to swap out libc at run-time, at least without swapping anything else that's linked to it. Maybe that's possible running on a ram-disk with a statically linked kernel and e2fsprogs/util-linux, but that's almost a chroot anyway, and it sounds far more precarious. The same can be said for the sanitized headers, you could change them but the first package built against the new one could very well flip out at libc.
If you look at the packages in the base LFS build, and then subtract the components of the toolchain and the kernel itself... What is left is essentially all version-interdependent software, if any one of them changes just a little two much, all kinds of things can start breaking. I mean, what's the chances of getting anything built or installed if Sed isn't working?
Go download a base Gentoo and get it built and running. Then just try changing LANG and watch what happens. That might give you some insight as to how far down you can make a change before it starts rebuilding world.
If I was going this route, I'd handle it something like this:
Build LFS base.
Build the packager dependencies.
Build the package manager.
Boot from a LiveCD and tarball /
You then have your base dependencies, build tools are in place and a functional kernel. This is basically how Gentoo does it with their Stage 3 tarball.
After this you can try to decouple and isolate some of the earlier packages, which might work with anything that you can rebuild in place like Grub or Sysklogd. But, I don't think you can get much lower than this. For instance, I don't think it's possible to swap out libc at run-time, at least without swapping anything else that's linked to it. Maybe that's possible running on a ram-disk with a statically linked kernel and e2fsprogs/util-linux, but that's almost a chroot anyway, and it sounds far more precarious. The same can be said for the sanitized headers, you could change them but the first package built against the new one could very well flip out at libc.
If you look at the packages in the base LFS build, and then subtract the components of the toolchain and the kernel itself... What is left is essentially all version-interdependent software, if any one of them changes just a little two much, all kinds of things can start breaking. I mean, what's the chances of getting anything built or installed if Sed isn't working?
Go download a base Gentoo and get it built and running. Then just try changing LANG and watch what happens. That might give you some insight as to how far down you can make a change before it starts rebuilding world.
I highly doubt B/LFS will ever get a built-in package manager other than the combination of pkg-config and Make. There's more than enough documentation in the book that having a package manager is next to useless for someone knowledgeable enough.
Package Managers are like auto-dependency resolution. Useful tools only for the unskilled... IMO.
Extra work would have to go into the book to perform such a feet and I doubt the maintainers will ever do such a thing.
One package management technique called FakeRoot is hinted at by the book, but is not officially supported. FakeRoot is virtually a tarball drop-in package technique that leaves post-install and setup up to the maintainer.
I highly doubt B/LFS will ever get a built-in package manager other than the combination of pkg-config and Make. There's more than enough documentation in the book that having a package manager is next to useless for someone knowledgeable enough.
Package Managers are like auto-dependency resolution. Useful tools only for the unskilled... IMO.
Extra work would have to go into the book to perform such a feet and I doubt the maintainers will ever do such a thing.
One package management technique called FakeRoot is hinted at by the book, but is not officially supported. FakeRoot is virtually a tarball drop-in package technique that leaves post-install and setup up to the maintainer.
I'm not real interested in it but I did see in the hints http://www.linuxfromscratch.org/hint...using_trip.txt
But it very old, not sure if its any use.
Trip look like it was written for LFS, I haven't seen any other reference to it.
I use Pacman and I install it and its dependencies in the toolchain, in chapter 5 directly after the last package from the book. Until libarchive I just add: zlib, openssl and libarchive.
I think it's great to have a package manager. I run the same system on 2 machines, and I build new packages on any of them and then just put in my dropbox and install on the other. Actually, I don't see my system as an LFS-system, I see it as my own distro. I keep it updated, and a package manager also makes it easy to downgrade if something goes wrong.
I highly doubt B/LFS will ever get a built-in package manager other than the combination of pkg-config and Make. There's more than enough documentation in the book that having a package manager is next to useless for someone knowledgeable enough.
Package Managers are like auto-dependency resolution. Useful tools only for the unskilled... IMO.
Extra work would have to go into the book to perform such a feet and I doubt the maintainers will ever do such a thing.
One package management technique called FakeRoot is hinted at by the book, but is not officially supported. FakeRoot is virtually a tarball drop-in package technique that leaves post-install and setup up to the maintainer.
I think being organized never hurts and simple package managers like crux's one really helps.
When I build a base LFS system, I incorporate everything from the LFS book, plus the recommended additions at the end in the Rebooting chapter as well as some of my own:
After that, I create a tarball of the entire system, similar to a Gentoo Stage 3 tarball. This becomes my base OS to work from and reissue if and when needed.
Afterwards, make install and make uninstall manage everything else from the /usr/src directory. When errata releases are made, I then do a dependency track of the software and see what uses it, and then rebuild packages as needed.
It sounds like a lot of work, but its actually the opposite.
You just tar the whole / partition?
And by the way I am still writing the pkgfiles and building LFS. I just got home from holiday and I will keep writing them. For anyone interested on it: https://www.dropbox.com/sh/xbn54wwnehlnkzo/KjAGkjs2oc
Yep, I tarball the whole thing, but from a Live Disk to make sure everything is unmounted and unused.
That's basically a Stage 3 tarball. A finished base system tarballed to be backed-up/archived.
I actually don't run chapter 7 (post-installation and bootloader + kernel stuff) or later (including any specific other system only setup of packages) before backing up the archive. I just unpackage and install everything, finish Chapter 3 of BLFS, install my list of extras, then clean up the source archives and move them to /usr/src along with my build scripts. After that I backup the system with tar and save it to an offsite FTP.
Distribution: LFS 9.0 Custom, Merged Usr, Linux 4.19.x
Posts: 616
Rep:
I was thinking about this last night. It might be easier to use CLFS if you want to package everything. That was you can stay chrooted for everything, they even have multilib setups. If you make scripts to get in and out of your chroot quickly and are using VMWare you could do something along the lines of:
Dupe the chroot volume on the host.
Mount the chroot volume in the guest, chroot and build and install.
Exit the chroot back to the guest and mount the before-build chroot vol on another mount point.
Do a filesystem diff on the two of them to see everything touched.
If you could streamline most of that with scripting you could easily see everything done on even the largest and most complicated installs.
Distribution: Linux From Scratch, Slackware64, Partedmagic
Posts: 3,129
Rep:
Quote:
Originally Posted by Luridis
...It might be easier to use CLFS if you want to package everything. That was you can stay chrooted for everything...
You don't have to use clfs to build a complete system in chroot, I built the entire system I am using now in a chroot, and in fact am building another one as I type.
You just have to be aware that some things are slightly different in chroot than not.
You don't have to use clfs to build a complete system in chroot, I built the entire system I am using now in a chroot, and in fact am building another one as I type.
You just have to be aware that some things are slightly different in chroot than not.
chroot is beneficial for a lot of things, but when you start getting into some of the post-installation setups, you have to be inside your machine because it's checking for drivers to be loaded in the memory and other kernel functions executing.
To be honest, I do often build X in chroot, but I've also switched to using a build script set to do it natively in LFS. It really helps with some of the setup as well that you're inside your actual loaded Linux environment.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.