> 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 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. David -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
