> Date: Fri, 05 Jul 2013 18:06:25 -0500 > From: Bruce Dubbs <[email protected]> > Subject: Re: [blfs-dev] BLFS Package Currency > . . > > It's interesting that I recently did a BLFS build for myself without > considering if the packages were the latest or not -- just what was in > the book. It helped that I already had scripts for about every package, > but a lot had to be updated in generally small ways to get to the BLFS > package version. I generally had to comment out the tests because I > didn't want to take the time and I figured the editor that last updated > the book had done that for me. > > The packages selected were those that I wanted to use. I didn't build > everything, but I did build xfce and kde. The order of packages was as > the dependencies dictated. > > I was actually suprised in how easily things went together. There were > very few problems. Getting from LFS -> Xorg -> WM is a pretty long > process, but BLFS seemed to work as intended. > > Right now I'm up to a little over 300 BLFS packages. > > -- Bruce >
I'm interested in being able to measure objectively, and automatically, how coherent (wrt, tho' not limited to, functional interdependencies) is any particular dev-stage of software systems like BLFS. Do you know _why_ the build seemed to be OK - 'how easily things went together'. Could you apply the same methods to _make_ a subsequent build, from any given commit-'release', go similarly smoothly. What definition are you using of 'how easily things went together': is it 'just' that they all build ok, &/or pass the respective built-in test-suites, &/or you have an ad-hoc manual or automated set of extra tests, &/or you just use generally use the build in your normal workflows for a while and see if it feels ok, or what. 300 blfs packages is, iirc, still quite a minimal system: istr (from automated calcs of dep-chains in blfs) that seamonkey running in twm, with no multimedia/desktop-env/print-scan-typesett at all, omitting much of each other chapter, and keeping the dep-chain as 'clean' as possible, came to ca 200 packages. How many of the packages that you built, differ greatly from the de-facto blfs (semi-)formal-release from early Nov 2012? That release is now just over 6 months old, and there have been a few periods of fairly quiet blfs activity during that time: so it shouldn't really be surprising that such a relatively-restricted build within that time-frame after a (semi-)formal-release, would still go ok. Would that account substantially for why things went smoothly for you. And from what I see of commits and mailing-list activity, in the months preceding the nov2012 release, folks _were_ testing that things worked well together, as opposed to 'just' seeing that the package would build/install/selftest ok per se. Therefore, is the current and recent 'stability' and good foundation that you and others note, precisely because you and others, thru approx autumn 2012, essentially worked towards (whether intentionally a central goal or not), and created, a reasonably-tested formal-release. Now that you're further into a less-concentrated phase, will the commit-'release' model continue to work well. Again, I'm interested in seeing objectively if it does or not. In the present work-mode, when a person does a commit of a new version of a package, in what ways have they tested the package: and, are they building and installing and using the package from within (i.e. booted-into) a blfs version that is very close to the main repo HEAD; or are they in a chroot under the auspices of some other blfs-version or some other OS, and are 'just' testing build/install/pkg-testsuite. IOW, are the people doing blfs commits, running a pretty-much-always-recent(-ish) blfs-repo-HEAD as their OS, building & installing a new version of a package into that OS, checking at least basically that it works OK in their everyday workflows, and commits if OK? Or what? NB that I'm just _asking_ what in practice do folks do. Would the current level of blfs work be enough to ensure continued 'quite good shape': or would it require another period of extra-concentrated activity - like the one preceding the nov2012 (semi-)formal-release - to bring things back into line .... and hey presto, whaddyaknow, you've essentially got another (semi-)formal-release. IOW, for the commit-'release' model to seem to be 'working' just fine, will you essentially need to be creating (semi-)formal-releases anyway? On a separate note, the separation-out of sysd/gnome-ish/&c stuff might be quite a boon to BLFS. I recall how much of a drag gnome-ish stuff was on Slackware before PV cut the gordian knot and dropped it; and how much of a freeing from shackles was it for Slackware. It might be the same for non-sysd BLFS. And, the slightly-inevitable friendly cross-rivalry between the two books, might also be a boon for BLFS. rgds, akh -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
