-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/27/2010 10:52 AM, Yaacov-Yoseph Weiss wrote:
> >>> 2. Include more automation options with LFS. Including making sure they >>> work with the errata pages. > >>> 3. Include package management options, both for moving packages from >>> installation to installation, and for keeping track of installations. The problem with package management is that one flavor or the other is not perfect for everyone. I personally prefer a simple tar.gz package file. No dependency tracking or any of that. One suggestion I had made before is to use the DESTDIR method with tar.gz packaging, and go no further within the book, as that package, or rather the three sets of instructions (build, install, post-install) used to build that package, can be used nearly verbatim for all of the PM types (including verbatim for the users that like simple file lists. Here was the POC of Chapter 6 at the time, just the installation scripts, which are more than a little stale, but could be easily adapted for 6.6. http://www.linuxfromscratch.org/~dj/DESTDIR-LFS-6.4/ Others who already use RPM, have also duplicated the same work as the above, well before I did it, but the intention was to find a working middle ground for use in the book. Could even take it a step further and include the breaking up of bin, lib, and dev packages. Then it'd be a cake walk to copy and past into your deb-build, or spec, or whatever you can dream up. > >>> 4. Include several BLFS installation paths up to date. I'm not sure I understand that request. I've taken it to mean a linear BLFS. Is that what you meant? I'm afraid that the scope is far too great for that. I suppose that you could make the case to include *all* dependencies including reciprocal, and reuse existing XML, but IDK exactly how you'd go about it. I think we'd need some actual dependency tracking info in the xml source, and conditional code blocks based on those tracking items. Shooting from the hip here, one easy way I can think of would be to use specially formatted comment blocks, and a tool to pre-process the xml source before handing over to the tools to generate the completed book which would then be used by jhalfs. In fact, you could probably reuse quite a bit of jhalfs for this task. But, if I've understood the request correctly, you are asking for something to be done when we are already taxed for editors. The only way it will get done is if you, or somebody else, takes the lead and runs with it...give us a small, but working POC to get all googly eyed over first. This goes along with #2, but is only one (simple IMO, course I haven't tried it yet) way to handle it. > >>> 4a. LFS host system. Will include the host system requirements for >>> installing LFS. > > 4b. I would add to the list a basic X system. > X used to be in LFS, but I haven't put an X on a server that I've installed in probably 10 years or better. I did do a concept recently for an SBS replacement, which I'll be adding to later...likely after Samba 4 gets some more stabilization work done. > I would probably start with #2 and #3. I'll try to develop these further, > though > as this requires more thought, it won't do this on the spot. As a start, I > would > like to know what method of automation the developers use, and definitely > wouldn't mind seeing their scripts if possible. > > #4 and #5 would require coordination with BLFS, and could take advantage > of #2 and #3, so I would wait with them. > > Another task which could help keeping #4 and #5 up to date, (and ultimately > all of blfs) would be a (partially) automated test system which will at least > warn when updates to LFS cause the compiling of a later file to fail. Yes, but it'd go hand in hand with #2 and #4. - -- DJ Lucas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBAgAGBQJMT3eAAAoJEIUM+xKzBYsIkrEP/3qjA2zvw6xPhgecrWnYUlbw FiQtCvvn3zjhWiJAFF5JjPgp9nCw/dZ+zns04csuG41ek17s1y3PCvT/0uQqVHyk 6U7ThHnrwDWh+8Qu9U/v37us+X81YJFTiQP7hjVT5BbEKl08RUEo9Ko1Cp8BVynP WyrDqgOghYLxOFHzlPN8++43JlqbeRs0kIcoHrDsahKQer50aaRV3Vp6KgE+INoH U9u2HvT2VUStw8dOvq7sW8R8NX6n1DbwPIvlryt7HMSeRj0+cHE7yqN4j7z6RFO6 ghgtcD/lM5qLRKEZjvwRAy0cTZdtmVSCILfLjQy4pzVNrNUD9VcTXbxCc7Gk/bUt YzqhYOuDToqWxa7XhTn4a5Elg2iX9Ld36sMnSNzOjx/I3ln7OG41idyNHnwoxv3A D+/JjYU0OaJF3EO/pYzxpCVxbgl2cB19pHvXL+TO+REMXI9fyxAeiKw/WkQcA3wT 7cuWzSboyQFappny7YyTsj+afeLy852bQZNKEUZCVJIGu6Cqpw5zFP0HMKUUvXgS 3/6B4R5suN+c/ruwukqtnipLt5RyurUoN+BDJ1LLj6HLe3sPb2GApH+o9oTD/4dk Hqt0eUhRHRFOFCACq6e2hTgy9TkehFTez2hOpyhHeb8cH3Hr5cPEUrmkThoJ31Kg 4uRBg2ldHxU2X64oOQrH =CDol -----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
