> 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