| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On Tue, 2023-05-23 at 21:54 -0400, Christopher Michael Punches wrote:
> Dear ALFS Maintainers:
> First, greetings to all the smart people here. I am a big fan of the LFS
> project and its related projects.
> My name is Chris Punches. I am the BDFL for the Dark Horse Linux Project,
> which is responsible for a Linux distribution generated by a project called
> Pyrois, currently. Pyrois is able to draw from the LFS documentation to a
> degree of fidelity due to the way in which its automation component (called
> Rex) is designed and configured.
> I have some questions that I believe would be in both LFS', ALFS' and my own
> projects' interests for me to ask of you:
> Q1) --
> First, I am not clear on if the ALFS project is active or not. I may have
> made an assumption that it isn't. Please let me know if it is active. In
> case it's not, however, Pyrois currently draws from the 11.3-systemd LFS book
> with a degree of fidelity in a much simpler way than what I have observed of
> the approach ALFS uses.
The jhalfs project is active and maintained. See
https://wiki.linuxfromscratch.org/alfs/browser
I'm not sure what you mean with "Pyrois currently draws from the [...] LFS book
in a much simpler way than [...] ALFS. What is the method to extract
instructions from the book? Looking at the sources of Pyrois, it seems to me
that the instructions are hardcoded in bash scripts. So I am not sure how those
scripts are generated...
> So, I was wondering, did somebody here want to fork the current version of
> Pyrois as a new version of ALFS to re-energize the project?
I'd say jhalfs is enough for our needs, but if you have a great idea for
generating the scripts automatically from the books, it may be interesting to
compare with our currnt implementation.
> I would need to do a round of "cleaning up" to prepare it for that but I'm
> more than happy to do so.
> If so, soon would be a good time as I intend to build something else entirely
> on it from here, so I think taking a forked version from current or close to
> current would be appropriate.
> If no one is interested, no pressure -- as an alternative I am considering
> naming a fork of the the current Pyrois project as "ALFS-NG" (ALFS NextGen),
> in much the same ways syslog-ng and crosstool-ng named their projects and for
> much the same reasons. Would that be more appropriate? I am soliciting
> feedback on which approach to take.
jhalfs is copyrighted under MIT license. You can use the code provided you
acknowledge original contributions, or make something completely new and call it
as you want, as long as it is different from ALFS and/or jhalfs.
> For my own input on it, I will say that if I end up forking Pyrois to create
> an "ALFS-NG" unaffiliated with ALFS or LFS it would probably fall behind the
> LFS book quickly as I just would not have the time keep it up to date while
> building Dark Horse Linux out as a product so it would actually be more
> desirable to me at least if someone took over a fork of it. I'm sure I'd
> learn a great deal from its commit log as well, and I view all these projects'
> existences as important educational tools for future generations interested in
> the genesis of linux distributions. There aren't alot of places to learn how
> to do this that I've found.
> It should also be mentioned that in this projects' hands, a Pyrois fork as
> ALFS would immediately find itself in more capable hands from a coding and
> compiler knowledge angle. It is simple because a caveperson wrote it and
> hammered it with intent for a few years. That is perhaps good for foundation,
> but, in more experienced hands would likely be more able to grow.
> Q2) --
> Second, in the interests of good will, do you have any preferences for
> attribution, or would you need more information?
> I wasn't certain if this is the right venue to be asking these types of
> questions, so I thought I'd reach out. Please let me know where I should ask
> if this is not the place.
I'd say you're at the right place.
> Q3) --
> Wholly separate from the above, I have removed the requirement for mounted
> storage media and Pyrois generates a livecd ISO, with a writable root
> filesystem using overlayfs. That would deviate markedly from the LFS book,
> so, I thought it might be useful to mention it in case any of that was
> something wanting to be integrated over to LFS/ALFS?
LFS used to have a livecd project, but it was abandoned by lack of maintainers.
One of the devs of LFS maintains a builder which produces a livecd at
https://www.belfs.org/dev/browser/autolfs
> Q4) --
> I intend to use librpm and a dnf/yum package ecosystem with build hosts in the
> next steps of Dark Horse Linux / Pyrois in the fork not used by either ALFS or
> ALFS-NG. Advice on design/approach would be well received.
jhalfs as some limited capability to use package management. Presently the only
tested PM is porg.
> Q5) --
> Have you folks done any research on building an installer ISO that I can see?
> I have some ideas on an approach, but, I'm still debating which one fits into
> the broader strategy for DHLP.
See answer to Q3
> Q6) --
> Is there any interest in cross-project collaboration? If so, obviously I'd
> want to take it over to the mailing list hosted by Dark Horse Linux (details
> are on the website). While not yet a funded or connected project yet, I have
> high hopes for it.
We have a hard time maintaining LFS/BLFS because of the lack of people, so I
don't think we would be very active in collaborating. I wish you a good luck
with your project.
Regards
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page