Re: [RFC] remove obsolete clfs code in jhalfs

On Wednesday, February 23, 2022 9:35:32 AM CST James B wrote:
> On Wed, 23 Feb 2022 15:59:23 +0100
> 
> "Pierre Labastie" ([email protected] via lfs-dev Mailing List) <lfs-
[email protected]> wrote:
> > Hi, It looks like clfs has been dead for 5 years now, and clfs-embedded
> > for
> > slightly less.
> > 
> > I'd like to remove all the code related to this (and also some remnants of
> > hlfs code). That would reduce the code and make it easier to maintain and
> > update (it would be useful to add the possibility to build [1] for
> > example), specially because the code for LFS has evolved to be rather
> > different from its original design, while that of clfs has remained the
> > same.
> > 
> > But before that, I'd like to get comments from users to see if they would
> > miss the clfs support.
> 
> I'm not sure how CLFS supports in jhalfs looks like; I was under the
> assumption that jhalfs basically extract the build instructions from the
> book and then run it. I need to check before I can say anything further
> about it.
> 
> However, I just want to share the following food for thought.
> 
> I have a project that originally started with LFS (version 7.1), then went
> to CLFS, then "adopted" LFS to build using CLFS model. One of the reason to
> do this was because CLFS supported multi-lib from day one (Thomas' multilib
> didn't exist until much later, I think); and I didn't use CLFS wholesale
> because their packages are targetted for embedded systems and I was
> building a desktop system, where LFS choice of packages are more
> appropriate.
> 
> I had done this two times - Adopted LFS 7.5 to CLFS 3.0, and then LFS 8.2 to
> CLFS 2017.7. Both were not a big challenge as LFS/CLFS were about the same
> age, so only minor version differences.
> 
> As my project is getting stale, I was about to the same for LFS 11.0, but
> since CLFS is now in a coma (I still refuse to accept that it's dead), I
> had to apply it to CLFS 2017.7 (the most recent version); and I'm
> pleasantly surprised to say that despite the fact that LFS 11.0 has
> undergone major changes, the actual software packages do not, and the
> adaption works smoother that I expected it would. Of course, changes were
> required (in addition of what is already documented in LFS 11.0), and so
> the build order, as well as additional packages, but they were overall
> minor changes.
> 
> So, despite that CLFS is in a coma, and has not been updated for years, its
> instructions (suitably updated for current package versions and
> dependencies) will still build the current version of LFS.
> 
> cheers!

Greetings,

As a previous dev of CLFS, it wouldn't hurt to keep it in jHALFS, but also 
wouldn't gain much of anything keeping it in there. I built a clfs sysroot 
with current versions of packages for an M68K KISS 68030 system recently. The 
historical value is great. Keep it or remove it, fine either way.

My focus is on ARM in LFS. A future focus may be a Power9 system from Talos.

007 brings up a good point. Valid.

Sincerely,

William Harrington

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-dev
Unsubscribe: See the above information page