> 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:
> >> .
> >> .
>
> 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)
> >>>
In the _rendered_ books, the changelogs are listed in usual chrono order;
you don't want users to have to skip back'n'forth between two lists
(master+sys{v|d}) to try to piece back together a single chrono list
for the rendered book that they're using.
For sysv _rendered_ book, the 'changelog' page should show common+sysv
changes in normal chrono order. You can link to appendices that
show other diced'n'sliced, separated/combined, with/without labels,
changelogs. And likewise for sysd _rendered_ book.
If there is essentially single-src xml/&c per package/book-page, that
covers sysv/d, then presumably there would be some sort of structure
in the xml/&c to indicate parts relevant to only sysv/d respectively,
and the other parts would be (auto-)regarded as common.
You can then readily auto-detect which parts of an xml file has
changed, and so auto-classify its change-type as a permutation of
common/sys{v/d} .
(Depending on how you wire things up, you can also have commit-message
data directly in xml/&c src, and have it auto-extracted and fed into
scm as commit-msg.)
'Use the src': you've got a huge amount of info there that's mostly
well-structured; and is amenable readily to automated dice'n'slice in
whatever way you want. IOW, don't contort your src structure to try to
do things that the src-parsing _programs_ should do.
> >>> 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
> >
>
((
I'd expect that there would be much interest in a third variant of the
book, namely: one that _does_ show the if-else stuff rendered on each
single per-pkg/&c page. Yes, folks can sit with the separate sys{d,v}
books side-by-side, and do visual or automated diffs - or indeed
read the single-src xml directly; but others, I'd expect, would be
mostly interested in a _rendered_ version. This would help folks to
see readily just where do the differences/similarities lie (at least,
as far as practical b/lfs is concerned).
))
>
.
.
>
((
Also: be sure to still be able to decouple the/any combined b/lfs books
readily, if/as/when necessary.
))
rgds,
akh
--
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
