> 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.
--


>
> > 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.


> >
> I am not in favor of doing that either. That seems asinine to me, and 
> increases the difficulty of understanding the book and maintenance.
>
> > But depending on the number of changes, I might support doing BLFS that
> > way.  That would be a reasonable change that would support renumbering
> > to 8.0.
> >
> That would make sense for BLFS depending on the amount of changes.


Popcorn, Pt II ... ?  ;)



rgds,
akh





--
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to