> 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