Am Sonntag, den 31.03.2019, 10:04 +0800 schrieb Kevin Buckley via lfs- dev: > Hi there, > > I'd be interested in some feedback, should anyone have a chance to > look at things, as to how best to leverage SVN to add "mutiple > rendering pathways", so let me expand on that. > > The build system for the vanilla LFS book already has the ability to > branch on SysV or SysD. > > Thomas's patch adds multilib capability to either of those pathways. > > I am looking to apply a "PkgUser" (the More Control hint) approach > on top of that. > > My local (file-backed) SVN repo contains a mix of direct PkgUser > modifications, along with things such as > > 2>&1 | tee ../make.out > > being added into (hopefully) all of the various make commands, so including > the "make check/test" and "make install" stuff. > > I also make a few changes to <scree><userinput> blocks so as to remove some > things from the output generated by the book's Makefile's dump-commands > target. As you surly have seen, the ML stuff is controlled via 'arch="multilib"' or 'arch="default"' profiling attributes in the books sources. Using them made it possible to switch on/off the ML modifications at rendering time by setting a parameter to 'make'. So if set to "default", the rendering output should be exactly the output you get when using the original book and not using ML at all. You may use such a profiling attribute for your modifications as well but unfortunatly, docbook in the used version has only a limited set of those attrs while its possible to introduce own ones. > > What's not been clear to me in trying to store changes within my local > SVN repo is how to seperate things out so that for example, i could > apply a "PkgUser" SVN diff to a vanilla LFS XML source tree if it > hadn't had Thomas's Multilib patch already applied. > > Another one along the same lines is the make redirection stuff that > I add into my own books. That is what kept me busy for a while to get things done like you described. Goal was to minimze the impact on the "infrastructure" of the book (modifying the Makefile etc), simply be as much "compatible" as possible. Even jhalfs (with a few modifications DJ made) runs on the ML-variant. Finally, I end up with:
Create a local copy of the LFS repository (svn checkout). This repo can be updated simply via "svn up". Than, i created a copy of the book (directory BOOK) and made my modifications there. A diff between this directory and the original repo is what is known as the multilib- patch. Same procedure is made for the so-called "belfs extensions" which are modifications i like to have in the book but which are surly nothing to ever go to the original book. For example, in this variant i use the base kernel sources and a patch to get them uptodate (linux- 5.0.tar.xz + patch-5.0.4.xz) simply to save diskspace and download time... To keep things uptodate, i run a script which does: - diff the ML working dir and the upstream repo and store the patch in a temporary location - diff the BELFS working dir and the upstream repo and store the patch in a temporary location - update the upstream repository (never to that before the first two steps has been made) - duplicate the original sources into the ML working dir (via rsync -- delete) - apply the temp-patch to it - create the ML-patch (now this patch is against the most recent original sources) - duplicate the original sources into the BELFS working dir - apply the temp-patch to it - create the BELFS-patch - duplicate the original sources into the "merged" working dir - apply the BELFS-patch to it - apply the ML-patch to it - copy the BELFS- and the ML-patch to my website This process runs every day at 04:45. I use the interdiff utils to see whether there are differences between the previous and the newly created patches. If none, the new patches are thrown away. The description sounds a bit complicated but usually the process runs well, from time to time some .rej are created. That happens if there are modifications made in the original repo which are in conflict with my modifications. Then i have to fix that manually. I use the "merged" book for building my machines. Problem in this approach is that i cannot track my modifications in a SVN repository since the BELFS and the ML copies are simple file copies and are not under SVN control. The only history i have is that i keep the previously created patches. Next step will be to make a branch in the original repository for the ML part. > > Whilst that's not realy PkgUser specific, i could see that a standlone > SVN diff that applied just that might be useful to some folk, but again > it's not clear how to seperate things out when using SVN across the > two "regimes" I am adding stuff on top off, namely, the vanilla LFS and > the Multilib additional source. > > Any pointers/insight welcome. > Kevin > > PS > I have a rendering of my current book but am yet to stick it up on > the internet in case anyone wnats to take a look.: RSN. -- Thomas -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
