> Date: Fri, 21 Feb 2014 20:04:15 +0100
> From: "Armin K." <kre...@email.com>
> To: BLFS Development List <blfs-dev@linuxfromscratch.org>
> Subject: Re: [blfs-dev] BLFS Systemd Additions
>
.
.
>
> I know what you meant. I have no problems with shipping package specific
> notes for now.
Yes, but could they be shipped as, say, diffs/patches against e.g. blfs-7.4
release (just an example - but in any case a known baseline); so that
folks can apply them as wanted (& against a known baseline - hence the
'blfs-7.4 rel' example).
Current-format shipping is not making best use, results-wise, of the work
that you have obviously done in obtaining that info: the info is not as
readily re-usable as it really could be - and I'd expect could quite readily
be, as the blfs-sysd changes that you've made look generally fairly 'clean'.
Do you maintain your internal changes as changes to xml tree, or what; is it
amenable to generating diffs/patches that folks could apply to main blfs
xml? This is realy the crux of what I was meaning: can you generate such
diffs 'at no(t much) extra cost', from the internal-format info that you're
creating anyhow? Would that be better expenditure of your resources than
writing up the large-ish text/wiki documents?
> Maintaining seperate BLFS is something I can't do alone
If the blfs-sysd changes are avail as patches, then I'd expect folks'd
come on-board more readily.
> and maintaining same instructions in one branch, then generating two
> different books is something I don't know a) to do b) if it's possible.
>
Had expected here that there _would_ be two separate xml trees, at least
for foreseeable, like for lfs. And then in time see how 'clean' the diffs
between the two can be; and from there if want to merge.
Didn't mean to be distracting folks away from blfs testing.
akh
> --
> Note: My last name is not Krejzi.
> --
>
--
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
