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.




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

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

Reply via email to