Re: Planning an overall direction for LFS
On Friday 29 February 2008 10:01, Alexander E. Patrakov wrote: Jeremy Huntwork wrote: I realized that taking such a variable approach as 'choose your own PM' would lead to such issues. The idea I had in mind to solve it would be to make the main spec files nothing more than perhaps very simple xml, e.g.: namesomepkg/name version1.2.3/version patchfile-for-patching.patch/patch configure./configure --prefix=/usr/configure buildmake/build installmake install/install Yes, you are working on the important task of defining a common ground for package managers beyond this tar mode. Thanks for this. However, I am not really ready to formulate the minimum set of requirements for producing viable RPM spec files yet. Of course, RPM-specific crap such as %configure snip (i.e., adding implicit ./configure arguments) is out of question. And I don't see why configure and build should be separate tags. I agree, any PM-specific macro shouldn't at all be used. While not all package managers keep configure and build as separate steps (in fact, I'm not aware of any that actually do have them as separate steps), I don't see any problems in keeping them separate. They're easily enough combined into the build() function of pacman, gentoo ebuilds, or any other package manager that does them in the same step. This way, they'd also be already separated for anyone that is writing their own PM system in which the steps are carried out separately. However, it seems that you are solving a wrong part of the problem. Your work will allow a _reader_ that doesn't want package management to omit this module from the book. However, if package management (even in this simple form) enters the book, all editors will have to add such XML _and_ verify it, in order to assure quality of their instructions. Such verification, obviously, requires using a package manager. I.e., you attempted to solve the problem for readers, not for editors. Of course, one could imagine that general non-PM-aware instructions and XML for package management will be written by different people, but what if Randy adds yet another Perl module required only by some obscure app? Who will assure the quality of packaging instructions? (no offense intended to any party) I think the editors should be concerned only with making sure the commands work in jhalfs or in a copy paste mode. Perhaps there should be PM-specific editors to verify commands work with their PM system. Differences in the commands for RPM or Deb could perhaps be in PM-specific tags like PM name=rpm or perhaps just rpm? I'd certainly volunteer for such a task. Anyway, that's just my thoughts. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Planning an overall direction for LFS
On Friday 29 February 2008 11:44, Bryan Kadzban wrote: On Fri, Feb 29, 2008 at 11:22:24AM -0600, Rich Edelman wrote: While not all package managers keep configure and build as separate steps (in fact, I'm not aware of any that actually do have them as separate steps), The package-user method's current scripts do. However, I'm not sure if that really counts, or if the fact that the current scripts treat them separately means they always have to be kept separate. The configure function is what I use to apply patches and seds and other stuff, too, but that could also be moved into the build step. I believe in the RPM scheme, patching and seds are taken care of in the 'prep' stage, after extacting the sources. configure is typically part of the build process there. I'm curious how to reflect this and the other pre and post install steps, do we really want to have pre-install and post-install types of tags? I guess in the original sense of having generic xml spec files, that's what would be done, though. I think the editors should be concerned only with making sure the commands work in jhalfs or in a copy paste mode. As long as they're split up sanely, I think that would work. There's only one way to *really* test it, though, and that's to run through it with some sort of PM system. Maybe a dummy system would be enough to verify that the right things are happening at the right times, but I'm not really sure how you'd test that either. I really don't think the various editors (some of whom use no package management at all) need to be concerned with each different PM that's in use, or any PM at all, which is why I suggested volunteers that test each PM-specific case. The editors just need to make sure patches and the overall instructions are up to date and correct. That'll take care of 90% of the problem right there. Those of us that want integrated PM options or whatever need to step up to the plate and do some work, too. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Test logs for 6.3
On Thursday 30 August 2007 12:12, Dan Nicholson wrote: Thanks, Rich. I've uploaded (and organized) the logs. http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/ http://www.linuxfromscratch.org/lfs/build-logs/6.3/DualXeon-3.2GHz/00-README Let me know if you want any information added or removed from the README file. Am I correct that you didn't run the testsuites? Oops, I knew I forgot to upload those. :) The test-logs are now available at http://www.quokworld.com/lfs/6.3/lfs-6.3-test-logs.tar.bz2. They're also available via http://www.quokworld.com/lfs/6.3/test-logs/. I only ran the test suites for 065-glibc, 067-binutils, and 068-gcc. If you want, I'll rebuild the whole thing with testsuites for everything, I certainly don't mind. This machine just sits here mostly idle anyway. Rich -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Test logs for 6.3
On Tuesday 28 August 2007 16:53, Dan Nicholson wrote: If anyone has clean test/build logs to contribute for the 6.3 book, please tar them up and post them with a hardware description. Preferably Ch. 5 and Ch. 6, but just Ch. 6 will do. They will eventually go here: http://www.linuxfromscratch.org/lfs/build-logs/ I have logs for the Ch. 6 tests form a Core Duo laptop. These were generated from jhalfs, which makes it really easy if anyone is interested in helping out. I'll be uploading them later today some time. -- Dan P.S. Same goes for development/ You can find my build logs (as a .tar.bz2) at http://www.quokworld.com/lfs/6.3/lfs-6.3-build-logs.tar.bz2. Or just browse around http://www.quokworld.com/lfs/6.3/logs/. My machine is a dual Xeon 3.2Ghz (hyperthreaded, heh), 2GB of RAM and a couple 250GB SATA drives. (Dell Precision 470). I used jhalfs-2.3 and the lfs livecd-x86-r2032 for my build host on this. Unfortunately the SBU values created don't mean all that much because there were a couple of packages (gcc and man-db) that failed to build due to MAKEFLAGS being set to -j5. Setting it down to -j3 allowed GCC to build, but man-db refused to build unless MAKEFLAGS was empty. Anyway, if wanted, I can send in that SBU report.. Total SBUs was like 163 or so (without building the kernel). Rich Edelman -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
