[blfs-dev] Possible BLFS systemd solution

akhiezer lfs65 at cruziero.com
Sun Jun 29 18:00:55 PDT 2014

> Date: Sun, 29 Jun 2014 21:55:37 +0200
> From: "Armin K." <krejzi at email.com>
> To: BLFS Development List <blfs-dev at lists.linuxfromscratch.org>
> Subject: [blfs-dev] Possible BLFS systemd solution
> Hello all,
> As you could see, few moments ago I've commited a "systemd2" branch,
> which contains a prototype of how I would try to create and maintain
> BLFS systemd book from single (fsvo single) xml source hierarchy.
> So how would I achieve that?

You wouldn't, at least not for any reasonable length of time: it's a
doomed approach. The problem isn't with xml/&c technologies per se: it's
with, essentially, the dep-chains and 'logic flows' of sysd increasingly
differing from and conflicting with, the *nix side.

What you describe below may 'work' after-a-fashion for the two projects -
sysd and *nix - as-is right now (and even then is not a good approach):
but it has no vision for how the two projects are likely to diverge over
the foreseeable future; or, alternatively, it sees all-too-well how you
might pollute and snuff out the *nix side (a form of EEE).

> Since there are far more packages that don't require any modifications
> for either systemd or systemv, 

Perhaps at the moment: sysd though is not interested in interoperating
with *nix; they are ever-/increasingly- diverging, and the roadmap shows
the rate of that only increasing.

> it would be a bit overkill to maintain a
> separate branch, 

Or, and by the same token: merging between two branches should be
pretty straightforward just now; and you are future-proofing against
gotchas/conflicts/&c - the aforenoted ever-increasing divergence and
outright contradicting conflicts.

The central and _*obvious*_ problem with the single-branch approach is,
again, that sysd has very different - and still much more rapidly changing -
and contradicting dep-chains and 'logic flows', from the *nix side.

Yet parts of b/lfs seems hell-bent on mixing sysd/nix in single branches,
inadvisedly, instead of using branching/merging/rebasing/&c&c technologies
like they normally would be. Part of b/lfs got bogged down just recently on
single-branch approach; and did not - and still has not - extracted itself
as 'simply' as it haughtily claimed it could and would as/when the going -
entirely predictably - got tough and eventually hit the brick walls that
had been pointed out to it several times.

Why do folks keep - disingenuously - wanting to pollute the *nix branches
with sysd, instead of having separate branches and doing any combined/merged
books from those separate branches. Why is there repeatedly exhibited such
lack of vision and good practice: it doesn't add-up.

> especially since it's impossible to keep up with Fernando.

That's a bit of a non-sequitir: if you have two branches then just merge,
if such merges would be as mostly clean as you imply above.

> I know this has been rejected in the past, but here I go again. Chris
> gave me an idea of having two different "chapter" files (the ones that
> contain all xincludes from a chapter) and let the "make" process decide
> which one should be used.
> So the idea would be to have:
> postlfs/security/security.xml.systemv
> postlfs/security/security.xml.systemd
> The first one would be the same as postlfs/security/security.xml
> currently is, just renamed.
> Packages that require modifications for systemd would be renamed to do
> that, ie
> postlfs/security/polkit.xml would be for systemv setup
> postlfs/security/polkit-systemd.xml would be for systemd setup
> The second one would be referenced in
> postlfs/security/security.xml.systemd mentioned above.

So having two branches is too much work, yet you'll effectively be wanting
to maintain two sets of xml files, in a single branch - and by what ad-hoc
means: that doesn't make sense - unless perhaps e.g. you're really going
to 'atomise' them via includes; and so-obviously doesn't make sense that
I think it's fair to raise doubts about why the single-branch is again
being proposed.

> This would require a small change to BLFS top level Makefile as well as
> renaming the chapter files in the current book. I have commited the
> "systemd2" branch for prototyping the chapter "Security".
> Only thing that would change for editors is to make sure they use
> chapter.xml.systemv or chapter.xml.systemd instead of chapter.xml for
> inclusion of new packages.
> Comments?

Again: keep blfs-sysd as a separate branch from blfs-*nix: that gives
you clear baselines from which to see how easy/awkward are merges to
any combined-book branch. And if any combined book becomes increasingly
awkward to achieve, then you still have the two clean separate branches,
instead of an increasingly convoluted single-branch.

Again: why not use rcs/vcs technologies properly. A Krejzi recently decried
another project wrt their use of rcs/vcs technologies: while here another
seems to be advocating *not* making basic good-sense use of rcs/vcs tech;
are the two related.

Armin: why not cut the gordian knot, and setup a git repo for blfs-systemd
and lfs-systemd, and the requisite git/svn bridges to/from 'traditional'
b/lfs svn: that would be a much better foundation; and I'd bet you _would_
build up a healthy lot of contribs to those sysd projects. I think that
part of the problem here is that you are trying to constrain yourself to
work within an unsuitable framework - you're almost being not bold enough
on the matter.



> -- 
> Note: My last name is not Krejzi.
> -- 


More information about the blfs-dev mailing list