On Mon, Mar 03, 2008 at 02:55:35PM +0500, Alexander E. Patrakov wrote: > 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. > > [X] I am an editor of LFS or one of the related projects > [X] 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) Just to be clear, I only use true LFS when I'm running on x86. Last month, that was just about every day. This month I'll be doing a lot more testing of clfs on other architectures.
> > 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 > ( ) Installation script tracing with some other tool > (X) Timestamp-based "find" operation > ( ) User-based > ( ) RPM > ( ) DPKG > ( ) Simple binary tarballs produced with DESTDIR > ( ) Other DESTDIR-based method of producing binary packages > ( ) Other That looks too much like a /. poll. Comments on some of these options - "I trust the list of files" - editors are supposed to check this information when updating. "I rebuild eeverything every 3 months" - in my case, I'm an archetypal "rebuild frequently" guy, but I'm not sure I throw things out quite that quickly, and anyway I still need to know what gets installed. > > 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 > [ ] Ability to compile once, deploy on many macines > [ ] Scripting the build Actually, as I said earlier, 'find -newer' doesn't tell me where every file comes from (some headers are older than the timestamp). but, it works well enough for me. > > 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 > [ ] Can't be used to transfer packages to another machine > [ ] Interferes with config.site files described in DIY-linux > [ ] 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 > [X] Exists at all > ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
