[blfs-dev] Possible BLFS systemd solution

Armin K. krejzi at email.com
Sun Jun 29 15:25:08 PDT 2014

On 06/29/2014 11:58 PM, 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).
> --DJ

I didn't quite understand it at first, but now that I have I believe
this is the kind of solution that has been rejected last time.

Mixing instructions in the same xml document is not something everyone
was happy about last time we spoke about this. This is why I got the
idea like this.

As for "getting out of sync", 75% of the time, only the xml "header"
gets updated (url, size, md5sum) and we can share these with xincludes
if necessary. Merging is not a problem, there are not many packages that
really require big changes.

Note: My last name is not Krejzi.

More information about the blfs-dev mailing list