On 06/30/2014 03:00 AM, akhiezer wrote: >> 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. >> -- >> > > > -- >
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. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
