[blfs-dev] Possible BLFS systemd solution

Armin K. 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
>>> 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.


More information about the blfs-dev mailing list