Jeremy Huntwork wrote: > I think we need to bring something up in LFS. If a user decides he > wants to use a package manager, he's not going to want to find out > about his options *after* he's already built his core system and > moved on to BLFS. The minute a user starts building packages that > will be in the final system, he should be able to use a package > manager, if he so desires.
Definitely agreed. Any package management really should be used during the book's chapter 6, otherwise you get a bunch of files that you can't see which package they came from. (I saw this with the pkg-user hint; I had finished with the LFS book when I found it, but by that time it was too late to create all the extra users and change the ownership of all the files.) >> 1) Recommend it, put it in the book, with instructions how to do >> it, a la all the packages in LFS. >> >> 2) Present the alternatives and let the readers make a choice. >> >> 3) Simply mention the guiding philosophy and let readers find >> different solutions and choose what works for them. I'm not reading what's there as a specific endorsement of one particular package manager. I read it as "If you want a package manager *that's geared to LFS*, then try this one." It's a conditional recommendation. Basically, the first part is Randy's option 2 (present the alternatives) -- it's just that the BLFS book is doing the presentation. The second sentence could perhaps go, since it's mentioned on the BLFS page, but I guess I don't see how it's hurting anything.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page