I use pacman for my LFS and am _very_ pleased with it.
On Thu, Jul 15, 2010 at 4:20 PM, <[email protected]> wrote: > I didn't read each single mail (to be honest just the last ones) and I > don't know if it was already mentioned but for me I found pacman as my > package manager. > > Here is a hint which explains how you can install pacman with the > temporary system in chapter 5: > http://www.mail-archive.com/[email protected]/msg00030.html > > I'm not finished with my system because of time issues but my > experience so far is that it fits very well. > > Here are my reasons why I want to use pacman: > > 1. you build your packages from source > 2. you have full control of the building process > 3. you can (and should) build the packages in a fakeroot environment > (sandbox) so no file in the root filesystem can be overwritten. > There exist packages where you cannot use make DESTDIR=... install > but make root_dir=... install or anything else so package building > process fails and you can correct it without any file to be > overwritten. > 4. pacman stores its package information in plain text files > 5. you can specify config files of the package for backup so your > config files don't get overwritten by an upgrade or deleted if you > uninstall a package for any reason. > 6. you can delete files in the package like /usr/share/info/dir and > use an install script instead which updates this file. > 7. you can split packages like gcc in gcc-libs and gcc if you want > some systems without a compiler for any reason. > 8. you can build your own package repositories so packages build on > one system can be easily used on other systems with the same > architecture without recompiling. > For example, I'm currently using a virtual machine on my server as > a master where I build my packages and keep an repository and the > plan is that I can update my packages on my laptop easy with > "pacman -Syr" > 9. You can install the same package with different versions by prefix > them with /opt and giving them another package name, i.e. > foo-1.0 in the root filesystem and foo-test-1.1 in /opt > 10. If you have some trouble with a package you can look in the > archlinux package repository how they build the package and it > could give you an idea how you can fix your issue. :) > 11. You can have multiple repositories, i.e. stable and testing and put > any new package (or version) first in the testing repository and > if it seems to work move it to the stable or just switch back to > the stable version of the package. > > So, why not change to archlinux? I think if you have used your own LFS > system for a while you don't want to use any other system/distro. I > think you know what I mean. :) > > Christian > > > Thursday, July 15, 2010, 6:47:43 AM, you wrote: > > BD> Michael Shell wrote: >>> >>> Forgive me if this is something trivial or otherwise already well known, >>> but all I ever wanted in LFS package management is something that watched >>> the installation from source and recorded what files were installed and >>> where for purposes of later *deinstallation*. > >>> The idea here being that all installation/upgrades would be done from >>> source - true to LFS - but, a simple application could be called to >>> deinstall/yank already installed packages either because they are no >>> longer needed or prior to an upgrade where the older version (e.g., >>> libraries) is not wanted (e.g., if something else breaks on the new >>> library without the old that would get upgraded too). > >>> It would also be really great if there was some sort of "write sandbox" >>> where "make install" would be able to read from the root filesystem as >>> normal, but any writes would go to a "sandbox" "empty mirror" filesystem >>> so that all the installed files could either be packaged or >>> copied/installed after human "inspection and approval" (e.g., see what >>> it has written/altered before it is allowed to do so). This would also >>> be a safeguard against a malicious installer. Thus, final installation >>> could be done via a simple "cp -a" (of course, a simple copy could not >>> handle any "post" additions/alterations of files). > > BD> For most packages you can do 'make DESTDIR=/tmp/package install' and the > BD> tree will be installed there. Doing a ls -R /tmp/package gets you the > BD> list of filenames. > > BD> One problem with this is that some files get modified, not replaced. > BD> For instance /usr/share/info/dir. > >>> It would be nice to be able to see a list of things that depend on a >>> given application/library, but this is optional. And as James said, >>> such things should be done with self-contained databases, or even >>> better, just plain text files organized using the filesystem. > > BD> That's really hard. Many libraries have no idea what packages use their > BD> functionality. The same can be said for utilities like sed, grep, etc > BD> that are used from within a program (like a shell script.) > >>> FWIW, IMHO, the RPM package manager started out as a good concept, but >>> then became so bloated as to be a sick joke with regard to dependencies. >>> The RPM package manager is often the first thing to break during upgrades >>> and the last to be restored. It is too fragile with regard to what it >>> depends on to be able to rely on it when your system is in trouble. Blah! > > BD> But what is the alternative for most users? If you just want to use a > BD> system, you want the dependencies to be taken care of for you. The > BD> installation and upgrade process is inherently complex. When you get > BD> packages from multiple sources the probability of breaking something is > BD> really quite high. In some cases, the only real solution is to > BD> reinstall everything. > > BD> LFS actually gives the most flexibility of all, but the upgrade path for > BD> a package is usually installing over the old package. Most of the time > BD> that's ok. It does leave some breadcrumbs around, but usually they are > BD> not significant. One of the reasons I use /opt for things like qt or > BD> kde is so I can upgrade to a new package without blowing away the old > BD> one. I really don't know of any regular distro that allows that. > > BD> -- Bruce > > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
