> Date: Sun, 29 Jun 2014 21:55:37 +0200 > From: "Armin K." <[email protected]> > To: BLFS Development List <[email protected]> > 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. > -- > -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
