On Mon, Jun 15, 2020 at 09:25:04PM +0900, Akira Urushibata via lfs-dev wrote: > 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. >
I have no experience of using Arm, and I don't know of any Arm machines which would appeal to me for compiling software - I've seen one recent review of an aarch64 machine configured as a desktop box at phoronix, but it was expensive and mostly a lot slower than similarly-priced x86_64 machines. And I suspect that what works on 32-bit ARM might be different from what works on 64-bit. But more generally - I don't think anyone deliberately breaks packages for current releases, but strictly the "works on LFS-9.1" tags are for the then-current version. Tagging what parts of BLFS work on a different architecture is never going to be up to date unless BLFS moves to support diverse architectures - but then it would be like gentoo (various different versions marked as 'stable' on different architectures) or CLFS (my memory says that random packages in their wiki had different versions or different instructions for different architectures, but of course some of that was for multilib - was it MIPS which had _three_ architectures?). Needs a LOT of developers, and less churn of package versions (in some ways that might be a good thing, with updates not public until thoroughly tested, but a big problem when serious vulnerabilities appear). > 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. > But what I, you, and anyone else regard as high-priority will inevitably be different things. For example, on my home server I only regard apache and its deps, git and the mail packages I use, as high-priority. Oh, and ssl/ssh. And on desktops we try to support a wide range of packages - there are many in the book which I have either never built, or have stopped building. But people who use gnome (in either book) or kde will have very different cares from mine. > 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. > Arguably, it's the same story - needs more people. The overriding problem is the churn of new package versions, many of which end up with modified instructions or dependencies. I suppose that the (LFS) translators will not be overjoyed by LFS moving to cross2, and will appreciate help when that happens. But everyone has limited time, and it's best to use time for what the individual cares about. ĸen -- So it's not 'I think, therefore I am', it's 'The computer thinks, therefore I think I am'. I've never actually thought about that before. -- Rimmer (a hologram), Red Dwarf, 'The Promised Land' -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
