On Sat, 13 Jun 2020 Pierre Labastie wrote: > the problem is not lfs, but blfs. There are around 750 packages in > there. If those packages are all updated twice a year (some have > much more frequent updates...), it makes 4 updates per day, 7/7. > Updates mean: get the source, check it is right (gpg signatures, > whatever), update size and md5. Build and test it, analyze and > restart when something gets wrong (very often, the instructions for > one version have to be changed for the next one), measure and update > sbu and disk usage, do a "DESTDIR" install to check new installed or > not installed files and dirs. Update the xml, publish. Also check > that dependent packages still build (not always done, actually, but > it means that full builds of blfs must be run from times to > times). Most of this cannot be automated because of the diversity in > upstream sources and build systems.
I don't think all the above is necessary for ARM-BLFS. Judging from Pi-LFS most packages should build without special adjustments. There is no difference in the source package location, MD5 sum and dependencies. There is little need for a separately measured SBU. So for most packages I think that stating that the instructions have been tested on ARM in addition to x86-32 and x86-64 and are known to work would suffice. A dependency matrix for BLFS and some amount of build automation would be nice. The 750 packages are not equally important; there should be some mechanism to determine which ones have priority. By the way translation is a different story. One person has been working on translating LFS and BLFS into Japanese and he says he can't keep up with BLFS. -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
