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
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
