----- Original Message ----- From: "Alexander E. Patrakov" <[EMAIL PROTECTED]> To: "LFS Developers Mailinglist" <lfs-dev@linuxfromscratch.org>; "BLFS Development List" <[EMAIL PROTECTED]> Sent: Monday, March 03, 2008 10:55 AM Subject: Poll about package management
> Please reply to this message (please, limit this to the lfs-dev list > only) and mark with "X" the items that apply. If the answer is not the > same on your different Linux systems, write numbers of systems to > which each answer applies instead of a simple "X" mark. The resuts may > or may not be used for determining the future course of LFS. They will > certainly be used to verify or disprove my guess about the way the LFS > community is now split. > > [ ] I am an editor of LFS or one of the related projects > [ ] I use LFS as my primary Linux system > [x] I use LFS on more than one PC (including virtual machines) > [x] I deviate a lot from LFS (not counting package updates as deviations) > [x] I deviate a lot from BLFS (not counting package updates as deviations) > > I use the following package management technique: > ( ) It's all in my head! > ( ) I trust the lists of files in the book > ( ) I rebuild everything every three months or less, so there is no > need to manage anything! > ( ) Installation script tracing with installwatch or checkinstall > (x) Installation script tracing with some other tool > ( ) Timestamp-based "find" operation > ( ) User-based > ( ) RPM > ( ) DPKG > ( ) Simple binary tarballs produced with DESTDIR > ( ) Other DESTDIR-based method of producing binary packages > ( ) Other > > I use the following features provided by a package manager: > [x] Knowing where each file comes from > [ ] Clean uninstallation of a package > [ ] Removal of obsolete files when upgrading to a new version > [ ] Ability to upgrade toolchain components (most notably, glibc) painlessly > [ ] Ability to revert mistakes easily and quickly by installing an old > binary package > [x] Ability to compile once, deploy on many macines > [x] Scripting the build > > I will ignore the future LFS advice on package management if it > [ ] Can't be applied on a busy machine where many files are > accessed/modified everyy minute > [x] Can't be used to transfer packages to another machine > [ ] Interferes with config.site files described in DIY-linux > [x] Will clobber configuration files wen upgrading package versions > [ ] Doesn't explain how to package software beyond BLFS > [ ] Requires learning another language/syntax besides bash shell syntax > [ ] Exists at all > One key point on package management is if package state data are written to a database or directly on a file tree. If a database could appear necessary with 1000 packages installed/installable, it could appear simplier with 100/200 packages to touch some mark on a file tree. File tree could appear simplier to hack vs db when you really want to do what the PM does not allow with good or wrong reasons to do what you want. The appropriate solution may depend on what is the target of the lfs build. A second point on package management is how much disk space (or flash...) the PM will need to work. Nobody care on actual hard disk size but this is a key point for flash/usb key system. IPCop actual package management is more like an embryo than a real package management. We basically know wich package install wich files FIRST in the order of LFS/BLSF build. We are not actually able to track when the same file is installed in the same place by a different package later in the build order. At the end of the full build, we are able to check md5 of all include files in the distribution. Then a manual selection is made to include needed files in one update (that is a mix of different packages upgrade). Concerning build, it may happen full build (except the toolchain that is packaged to win time) is made 5 times a day if this is needed or less frequenly. LFS would gain speed on rebuild using ccache. distcc has a far more marginal usage. In short, network has to be fast enought to beat local cpu, wich is usually not the case with powerfull cpu. Gilles -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
