akhiezer wrote: > ---- > * BLFS has been mandated, by yourself and others, and for the foreseeable > future, to be rolling-'release' (and there was some discussion on the > pros'n'cons of that).
Mandate is not the right word. We took that decision because we don't have enough volunteers to create a versioned blfs release. > * you want to track upstream formal, numbered-version, official, > non-dev-branch, non-"rolling", tarball releases .... Yes, and I'm starting that. You can follow along at http://anduin.linuxfromscratch.org/~bdubbs/chapter.html Right now Chapter 9 is a work in progress. > * .... and use them to create a non-formal, non- numbered-version, > non-official-, eternally dev-branch, non-tarball, rolling-, 'release' > downstream ongoing work-area (aka BLFS). > ---- > Aren't those kindof ... 'contradictory' (to hopefully put it politely). Not really. When, on average, there is more than one 'stable' package release every day. > Are you better, for BLFS, to aim instead to 'just' track the relevant upstream > repo branch-HEADs via git/svn/cvs/&c; of course, that'd still need some > heuristics, and not every upstream has such public-facing repos, and the > distinction between dev- and rel- can be quite blurred anyhow, &usw. But isn't > that approach a better fit for what you do with BLFS? And, continue to do the > (upstream-)formal-versioned-release tarball-tracking for LFS, which _does_ > (current[sic!]ly at least) have formal versioned releases. Size matters. There are 62 packages in LFS, 633 in BLFS, not counting xorg libs and apps. It would be a full time job just tracking what's going on. That's why I want to automate it. LFS is done and I'm about 10% through BLFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
