> Date: Fri, 05 Jul 2013 17:58:52 +0100 > From: "David B." <[email protected]> > Subject: Re: [blfs-dev] BLFS Package Currency > > > > You seem to have the wrong end of the stick: the automation is not being > > queried - that's pretty obviously required. What is being queried, is why > > are > > you trying to auto-track _tarballs_ for BLFS instead of just auto-tracking > > repo > > branch-HEADs via git/svn/cvs/&c (and per the caveats above), given how BLFS > > is > > rolling-'release': and contrast that with LFS, which is version-released in > > the > > usual way, and so a more logical fit for similarly- > > upstream-version-released > > tarballs. > > > > IOW, for BLFS you seem to be trying to grab static-objects (upstream > > tarballs) > > in order to create an intentionally non-static 'product'. Why not just go > > the > > whole hog for BLFS, and instead of upstream tarballs, focus on their git/&c > > repos; you can automate that just as readily as grabbing tarballs. > > The BLFS philosophy, as I understand it, is to maintain a rolling
"The current BLFS 'philosophy', at least in some quarters," - fixed it forya. > release comprising the current, stable versions of each package. That > way, it is possible to build a working system with a pretty high > probability that everything (or nearly everything) will work together > reasonably well. If BLFS adopted your suggestion, and took the current, > unstable, development version of each package, then the probability that > everything would work together (or at all) would be correspondingly > lower, and we would lose the practical benefit of being able to easily > build a working system. > Just for the avoidance of doubt: I think (fwiw) that a rolling-'release' is overall not a good(-enough) idea per se, whether based on upstream 'stable' or upstream 'unstable'; and in making the query was not advocating either, but instead was making the query within both the specific context of Bruce's intention, and the wider context of the current way that BLFS is done. I also do have some appreciation of how the current rolling-'release' attitude came about. It'd be perhaps interesting to quantify your probabilities: you talk about 'higher probability' - but is its absolute value high enough to be a valuable-enough tradeoff. Every commit to BLFS is a 'release'; and for each such 'release', how much new and extant breakage is there; and from 'release' to 'release', how does the breakage shift around randomly or otherwise across the span of BLFS. So if you want to build BLFS, and you take a 'release' and build from it, how much is broken and in what places. In practice you'll really need to take multiple 'releases' - recall that every commit is a 'release' - and blend them together, and to do so will likely 'need' to follow trac and dev-lists (neither are per se a bad thing) to see how your multiple 'releases' differ and can be blended, and often entail you re-doing earlier work - the sequences of commits are often as much shifting sands (that's not a criticism of blfs-devs) and circular routes, as they are a neat(er) linear progression. And _everyone_ essentially has to do this, entailing a fairly massive and unnecessary reproduction of work across users of BLFS. Sure, there can be side-benefits such as folks getting more familiar with the 'realities' of the lower-levels and inner-workings of the dev/commit process &c. But is that level of involvement a _requirement_ for using BLFS: or should the person be able to go and get a proper formal release and be able to work principally from that and not have to follow trac/dev-lists/&c as much as with the rolling-'release' scenario. IOW, by shifting to rolling-'release', I'd argue that BLFS has overall increased the barriers to entry, for folks; and _as such_ is overall now less educational. One sees far too often, and not just in computing, folks who are very closely involved with a project or type of work, and become very familiar with its processes and gotchas and messy areas and so on, seem to too-often 'progress' into a mode whereby they forget and now underestimate how important it is to present a clean interface to 'end-users' of their work; instead, they too-often become 'meta', breaking out the 'whalesong and joss-sticks', blogging about their 'processes', and start to mistake dumps of current-brain-state for coherent pieces of work. Every commit is a 'release'. For _your_ BLFS build, which 'release' are you going to use, "to easily[1] build" - or 'build easily' - "a working[2] system[3]" ? rgds, akh [1,2,3]: ymmv; depends on definition of terms; subject to change; depends on 'release' . -- -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
