[blfs-dev] Possible BLFS systemd solution

Armin K. krejzi at email.com
Sun Jun 29 18:28:19 PDT 2014


On 06/30/2014 03:00 AM, akhiezer wrote:
>> 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.
> 
> 
> 
> rgds,
> 
> akh
> 
> 
> 
>> -- 
>> Note: My last name is not Krejzi.
>> -- 
>>
> 
> 
> --
> 

The point of your reply is: Use separate branch (correct me if I'm wrong)

You have obviosly never merged between svn branches - it's worse hell
than the one you claim systemd has caused to Linux.

-- 
Note: My last name is not Krejzi.


More information about the blfs-dev mailing list