-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/27/2010 11:19 PM, Yaacov-Yoseph Weiss wrote: > > Not at all. I was suggesting tasks which the book could use in the > future. The only thing I requested at the moment is was to gage > interest in such direction.
I think that depends on the day of the week. ;-) > I have been thinking in the past about working on automation/PM, but > got the impression that no one was interested in any additions of this > type to the book. Unfortunately, most times anyway, a proof of concept must come first before anybody will listen. Take for instance Jeremy's community.lfs.org site for which this thread started. Most of us agree that the website is looking a little tired, but it took the mock-up to really get the conversation going. Then he introduced Redmine. I think I was the only one who really gave it a fair shot and bit at the usability issues, but they are out there now (at least as I see them)...and BTW, I like it. And on that vein... On 07/28/2010 12:07 AM, Bruce Dubbs wrote: > Section 6.3 discusses PM. It says why we don't have PM in the book. > > There are six hints on PM. On 07/28/2010 12:07 AM, Bruce Dubbs wrote: > Section 6.3 discusses PM. It says why we don't have PM in the book. > > There are six hints on PM. That is all fine and good, but there is a reason that this particular issue repeatedly comes up, at least one good long thread a year, if not more. The hints, while good, fall short due to a lot of manual intervention, and of course, parting from the rule of FBBG. Whereas, if the minimalist method of PM is included inline, then we have something usable that caters to these users that want PM as well. Ultimately, I suppose that it comes down to what is gained and what is lost. Installing from the DESTDIR is the minimal approach IMO, and is hardly even intrusive for LFS. Let's start with what is lost: Every page gets another small section with a make DESTDIR=blah install" and some additional commands that are normally run by the Makefile during the 'make install' phase. This is actually very minimal within LFS. From an editor's POV, there is the little bit of extra work that goes into searching the DESTDIR for info.dir files, oh and running ldconfig after every installation, I think we had to manually run grpconv and pwconv for shadow, and manually create the default vimrc, and that's about it for LFS. It gets quite a bit harrier for BLFS, but that's beyond the scope of discussion (pardon the pun). Now what is gained: Every page gets another small section with a "make DESTDIR=blah install" and some additional commands that are normally run by the Makefile during the 'make install' phase. This is very minimal within LFS. Yep, exactly the same argument as for the other side of the losses. For in do loops and install-info aren't used on a daily basis, and therefor provides an additional learning experience, granted not much, but they do give us an intro as to how the big distros do their packaging, and give the user an idea of what to search for in the Makefile when they go beyond LFS. Additionally, it gives an actual black and white picture of what is installed. Given the core goal of LFS, I would think that alone would be reason to move forward with it. Next, the difficult part of package management is contained in the book, so that those who wish to do more than just tar up a destination can do so. For instance, packages that do not use DESTDIR are identified and the (again, minimal in LFS) post-install commands are identified. Finally, we provide a fail safe if somebody makes a mistake during the process. I speak from experience, starting over sucks! I know, and I'm pretty sure that everyone can remember the dreaded "It would be easier to start over" response from years ago in LFS-Support. I have no idea if that response still lives on today, but I'd suspect that there are still cases of it. Heck of a lot easier than in the days of the reboot after static builds, but still. Which reminds me of another instance of something minor lost, but a lot more gained. Remember when the "Pure LFS" method was new? I used to build some static tools for a long time after that was gone for use in a glibc upgrade (something for which I haven't bothered with in quite a while). The least important gain IMO, is that you can simply skip the packaging all together and install as you always have. That is not a gain or a loss really, but an option that embraces the hints. I'm personally for it, so maybe I'm a little biased, but really, not much is gained or lost beyond catering to those who want to use a real PM and stopping these conversations from coming up in the future (or at least, reducing the scope of them). Give me a couple of weeks and I'll hack up a modified book for the POC (complete with remap="destdir" for jhalfs use) if somebody doesn't get to it first. I've been meaning to learn a little better how jhalfs works internally anyhow and this has given me just the excuse I need to get a better look at jhalfs/LFS/lfs.xsl. - -- DJ Lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBAgAGBQJMVIs7AAoJEIUM+xKzBYsIOC8P/RoqJBO7+i4d9NUVMEMXDZFN i74FBVM85wL8Fi1ZtcokomVrvyUzaPZ+4J7pj0D4jonZIOBJfOBPvE/xX7e1eAij d2Z5TbhN5ofvSu23cmigs6snsxvRmtsENUSrhcRbXlRms3H2vNmNl6vkib+VLmx5 LzhxmJll1g09heyjFEBlU7PoErUSSykguvNGHM8zUqaZ0WXZoq7Iu3GYBZQoEpYO 3dGyGfprqgdyBW/39daVn5kj8IqiTNK4p01kdvIDGe1Ni1eGTBpLYIjCiHn0tYuK rrEGiUeJWIFHBDkK7Zr0imnFuNeF2woa7VnkrP+TLZizsMOG5lUkazfKesNGVt+m 60u/eGjhK6J+QB2fI6tvyknFqkrhpHQGmnU7aHKrQm6A22clnTdC6SCwaIDm7ZEG 9Mq0UIjna0BFLAfhGAoNtBllUGOTWR6TmHnJjU8Ongs9du0fV7LuoRHuclnWLwlj XlB+x8x7dZ9PKtynJmX6TTu1Yt43MYxBb0X1f2Qodm0RfsSeoXQNE0jzOhAsQCgt ouSdQaA7G4xCdmiJGxvIzGveRgoR0R4vJ1gf8aOK6ee4fmOcIRvvkkdKFH3/aLMR 0yisMT8yY73ZPmtikHvEXL7p2D4HhjSDuMZ8tPGcBbR6vtiSIIlbSahNRcVABmub V3vyOgL8zoCHaijVN2Uj =GJly -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
