[blfs-dev] Possible BLFS systemd solution
krejzi at email.com
Sun Jun 29 18:28:41 PDT 2014
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
>>> 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:
>>> 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.
>> 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
>> See my example patch from 2014-02-22:
>> 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
> 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
> -- Bruce
Yeah, it's in my notes (2 more or less).
Note: My last name is not Krejzi.
More information about the blfs-dev