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
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
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
