On 06/30/2014 03:07 AM, Bruce Dubbs wrote: > DJ Lucas wrote: >> >> On 06/29/2014 02:55 PM, Armin K. wrote: >>> Hello all, >>> >>> As you could see, few moments ago I've commited a "systemd2" branch, >>> which contains a prototype of how I would try to create and maintain >>> BLFS systemd book from single (fsvo single) xml source hierarchy. >>> >>> So how would I achieve that? >>> >>> Since there are far more packages that don't require any modifications >>> for either systemd or systemv, it would be a bit overkill to maintain a >>> separate branch, especially since it's impossible to keep up with >>> Fernando. >>> >>> I know this has been rejected in the past, but here I go again. Chris >>> gave me an idea of having two different "chapter" files (the ones that >>> contain all xincludes from a chapter) and let the "make" process decide >>> which one should be used. >>> >>> So the idea would be to have: >>> >>> postlfs/security/security.xml.systemv >>> postlfs/security/security.xml.systemd >>> >>> The first one would be the same as postlfs/security/security.xml >>> currently is, just renamed. >>> >>> Packages that require modifications for systemd would be renamed to do >>> that, ie >>> >>> postlfs/security/polkit.xml would be for systemv setup >>> postlfs/security/polkit-systemd.xml would be for systemd setup >>> >>> The second one would be referenced in >>> postlfs/security/security.xml.systemd mentioned above. >>> >>> This would require a small change to BLFS top level Makefile as well as >>> renaming the chapter files in the current book. I have commited the >>> "systemd2" branch for prototyping the chapter "Security". >>> >>> Only thing that would change for editors is to make sure they use >>> chapter.xml.systemv or chapter.xml.systemd instead of chapter.xml for >>> inclusion of new packages. >>> >>> Comments? >>> >> You can do multiple <xi...> in the single chapter files if you want to >> have individual files in order to minimize editor changes for the normal >> book, but this will greatly increase workload for editors of systemd as >> they'll likely be expected to update both versions and keep the >> individual files synced when a non-systemd editor makes an update. This >> just seems like too much editor work in my opinion. Things are all but >> guaranteed to get out of sync with this method as changes from one must >> be mirrored in another. >> >> Personally, I much prefer using the profiles directly in the xml rather >> than having multiple chapter points. Once the revision attributes are in >> there, an editor that doesn't mess with systemd book simply need ignore >> tags with the 'revision="systemd"' attribute. We might still have a sync >> issue when text changes in those tags, but it's right there in the same >> file. >> >> See my example patch from 2014-02-22: >> http://archive.linuxfromscratch.org/mail-archives/blfs-dev/2014-February/026800.html >> >> >> >> In that example, I got a bit carried away in order to show all paces >> where it can be used, but if we limit the revision attribute to <title>, >> <para>, and <listitem> tags, and the three places (that's it for now, I >> think) where it will be required in the chapter.xml files, I think it >> could be both much cleaner, and much less intrusive to editors that have >> no interest in systemd. Addition of new files for existing editors would >> be unchanged and systemd editors can go and modify the file after >> inclusion. If you need a more complete example, I could probably do it >> up in a couple of hours. Another cool place where this could be used is >> for development and released books (rather than the manual process used >> now). > > I'm not really a fan of using xml classes to drive separate builds. I > don't think there is enough flexibility. > > I do have an alternate suggestion. Just create a separate index.xml and > for those chapters that need it, files like xfce/xfce.xml, > xfce/apps/apps.xml, and xfce/core/core.xml. Those index type files > could then call the base .xml files or alternate systemd files as needed. > > We could break up general.ent into two parts: one part with no systemd > impact and the two versions of the second part, one for sysv and the > other for sysd. I don't see an absolute requirement to sync every > package for both versions, but it should be easy enough to develop a > script to tell us when the versions differ. I can also see where some > packages might be in one version and not in the other. > > Finally, the Makefile could use variables based on the target or > environment variables to generate the correct instructions for the > actual build. Alternatively there could just be two different Makefiles. > > Armin, do you have a list of files in BLFS that need separate systemd > instructions? > > -- Bruce
Yeah, it's in my notes (2 more or less). -- Note: My last name is not Krejzi. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
