On Mon, Mar 3, 2008 at 4:55 AM, Alexander E. Patrakov <[EMAIL PROTECTED]> 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. > > [ ] 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) > [ ] 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: > ( X) 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 > ( ) 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: > [ ] 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 > > 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 > [ ] Exists at all > > -- > Alexander E. Patrakov > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > I have used LFS/BLFS both ways--to learn Linux details and as a primary system. When upgrading, I mostly trust the ./configure scripts to fail when an important dependency is missing/out of date, and mostly they do. If LFS does not end up including a package management system, I will most likely use something like Paco in my next build so that I have a reference to go to for figuring out which file belongs to which package. I would also be interested in a better integrated solution from LFS. Thanks for asking Alex. Best, Krzysztof
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
