> From: DJ Lucas <[email protected]> > Date: Sun, 22 May 2016 16:18:23 -0500 > Subject: Re: [lfs-dev] LFS systemd-specific stuff > > On 05/22/2016 02:57 PM, Bruce Dubbs wrote: > > akhiezer wrote: > >>> From: "Douglas R. Reno" <[email protected]> > >>> Date: Sat, 21 May 2016 20:04:32 -0600 > >>> Subject: Re: [lfs-dev] LFS systemd-specific stuff > >>> > >>> On 5/20/2016 12:57 PM, Bruce Dubbs wrote: > >>>> Douglas R. Reno wrote: > >> . > >> . > >>>> Also different: > >>>> > >>>> Chapter 3, but perhaps we can just agree to list all the files from > >>>> both > >>>> books there -- I think just systemd and dbus are added from the systemd > >>>> book, but I'm not sure. There may be something in the preface and > >>>> introduction too, but I haven't looked. > >>>> > >>> That is correct. I just looked through the Introduction and Preface: > >>> chapter01/how.xml > >>> is different. I agree on listing all the files from both books there. > >> > >> > >> Do you mean, that the _rendered_ books both just have the same > >> 'file-list' > >> &c content: > >> -- > >> * if yes, then would you give any indication of which items belonged to > >> which book: > >> ** if yes, then that'd 'violate' your if-then-else declaration > >> (per e.g. > >> below); > >> ** if no, then that's not good info for users of the books - not very > >> educational, likely confusing, and likely to cause much > >> repeated q&a > >> list-traffic. > >> -- > > > > It's a work in progress to validate a new process for the editors. > > There would be nothing really inconsistent to specify a full set of > > packages (trunk + systemd + dbus) and just not use the files needed for > > the book being used. > > > > Minimal use of dual profiles (<phrase>) (mentioned previously) would > eliminate that, but BLFS is completely different than LFS in this > respect. In LFS, it's not a big deal to keep separate pages for the 12(? > best guess) places where they differ significantly (3 removed and two > added for sysd, 2 removed 3 added for trunk IIRC, plus chapter 7). I > think we'd have, what, 5 <phrase> entries in the what's new page in LFS. > It's a one time change and wouldn't affect editors in the least. A > merged changelog for LFS would affect editors' workflow, which is > probably why it was overlooked last time I suggested it. In BLFS, many > pages would be littered with them, potentially one for each page that > installs a bootscript or unit for example (although, that particular > example might be able to be handled by an entity). And then we have > jhalfs, which I'm not sure if it uses the raw source or first pass. I > don't know a lot about the inner workings of jhalfs. > > > > >> > >>> > >>>> Chapter 1, change log and what's new, but perhaps they can be merged. > >>>> > >>> I am thinking that we could do it this way: > >>> Master Changelog (packages / changes common to both books) > >>> sysvinit Changelog (only to be shown in sysvinit, contains > >>> changes specific to sysv) > >>> systemd Changelog (only to be shown in systemd, contains > >>> systemd specific changes) > >>> > >>> That is very similar to how CLFS does it. > >>> > >>> I would say that the Whats New section could just be merged. All we have > >>> in there are the systemd and dbus entries. > >>>> Note that I am NOT in favor of changing LFS into a merged instance to > >>>> say something like > >>>> > >>>> if sysv do this > >>>> else if systemd do that > > > > > >> As any fule kno, that is of course essentially what you do in your source > >> code - in b/lfs's case, the xml/xsl/&c sources: and thus generate each > >> book with their respective infos, with no false-info 'bleed' across > >> generated books. > > > > If I may, that's exactly the problem. Maintaining two books has been the
Not sure if your wording is agreeing or disagreeing there. Anyhow: the point was being made for, in the _source_ materials (xml/xsl/&c (sigh) in b/lfs's case), and iff there's enough commonality: factoring the common parts; and _essentially_ ifdef'ing the other parts. It was/is kindof assumed as-read that that would auto-imply basically single-source. Your next para below seems to be of at least broadly similar view on at least that core aspect. (?) > systemd book constantly chasing trunk (and on rare occasion, systemd > giving something back to trunk). When ~95% of the material is identical > (a guess), or at least, is intended to be identical save for white space > issues (or other missed changes several revisions back), a fair amount > of time is lost keeping two sets of sources in sync. The percentage is > less in BLFS, but the same applies. Coincidentally, this is one of the > places where git would have a clear advantage (merges between differing > trees with the same ancestors). However, if for only that reason, it's > like using a jack hammer in place of an awl. Minimizing differences and > better use of existing tools is beneficial no mater the SCM tool. Merged > source completely eliminates git's perceived advantage (at least for > this particular problem). Bruce is exploring options to put our existing > tools to more efficient use and pooling resources (editors), while at > the same time, attempting to keep editors from having to change their > workflow too drastically (or at all in a ideal situation). > > > I'm not sure I follow this (one?) sentence, but I was speaking of not > > having an if/then/else from the readers point of view, not the editors' > > view. > > > > Of course BLFS is full of caveats that say if ... > > > > -- Bruce > > > > --DJ > rgds, akh -- -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
