mkinitcpio-install.sh: Concatenate units manually.

[dvzrv]

When running in chroot systemctl cat will not work (as no dbus integration exists). We therefore concatenate the units (top-most only) and any drop-in files that might exist in the various overlays.

Fixes #32

[Andrei-Pozolotin]

also lets not mark issue 32 resolved, keep it open for now

[Andrei-Pozolotin]

and then LGTM: feel free to squash/merge/release

[ml-]

damn, was only a few minutes away from submitting my review comments

[Andrei-Pozolotin]

never too late :-) what was it?

[dvzrv]

Ha, we can still add more changes in upcoming pull requests :)

[ml-]

@dvzrv @Andrei-Pozolotin Sure, we can do that in the next PR. Can discuss here though.

[ml-]

Also saw this in the systemd changelog, not sure about it yet:

        * Unit files now support top level dropin directories of the form
          <unit_type>.d/ (e.g. service.d/) that may be used to add configuration
          that affects all corresponding unit files.

[Andrei-Pozolotin]

@dvzrv looks like Matthias is right with the above review

[dvzrv]

Also saw this in the systemd changelog, not sure about it yet:

What would be the exact location for those dropin's though? /etc/systemd/system/service.d/? That should be fairly easy to add I guess.

[Andrei-Pozolotin]

https://www.freedesktop.org/software/systemd/man/systemd.unit.html

Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section headers. For instantiated units, this logic will first look for the instance ".d/" subdirectory (e.g. "foo@bar.service.d/") and read its ".conf" files, followed by the template ".d/" subdirectory (e.g. "foo@.service.d/") and the ".conf" files there. Moreover for units names containing dashes ("-"), the set of directories generated by truncating the unit name after all dashes is searched too. Specifically, for a unit name foo-bar-baz.service not only the regular drop-in directory foo-bar-baz.service.d/ is searched but also both foo-bar-.service.d/ and foo-.service.d/. This is useful for defining common drop-ins for a set of related units, whose names begin with a common prefix. This scheme is particularly useful for mount, automount and slice units, whose systematic naming structure is built around dashes as component separators. Note that equally named drop-in files further down the prefix hierarchy override those further up, i.e. foo-bar-.service.d/10-override.conf overrides foo-.service.d/10-override.conf.

In cases of unit aliases (described above), dropins for the aliased name and all aliases are loaded. In the example of default.target aliasing graphical.target, default.target.d/, default.target.wants/, default.target.requires/, graphical.target.d/, graphical.target.wants/, graphical.target.requires/ would all be read. For templates, dropins for the template, any template aliases, the template instance, and all alias instances are read. When just a specific template instance is aliased, then the dropins for the target template, the target template instance, and the alias template instance are read.

In addition to /etc/systemd/system, the drop-in ".d/" directories for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. Multiple drop-in files with different names are applied in lexicographic order, regardless of which of the directories they reside in.

Units also support a top-level drop-in with type.d/, where type may be e.g. "service" or "socket", that allows altering or adding to the settings of all corresponding unit files on the system. The formatting and precedence of applying drop-in configurations follow what is defined above. Configurations in type.d/ have the lowest precedence compared to settings in the name specific override directories. So the contents of foo-.service.d/10-override.conf would override service.d/10-override.conf.

Note that while systemd offers a flexible dependency system between units it is recommended to use this functionality only sparingly and instead rely on techniques such as bus-based or socket-based activation which make dependencies implicit, resulting in a both simpler and more flexible system.

[ml-]

Also saw this in the systemd changelog, not sure about it yet:

What would be the exact location for those dropin's though? /etc/systemd/system/service.d/? That should be fairly easy to add I guess.

/etc/systemd/system/service.d and /usr/lib/systemd/system/service.d

Edit: fixed. copy paste should be forbidden

About runtime: Consider or not? I don't think this is expected by the user in any way that runtime drop-ins are persisted into initramfs. I guess I also didn't think about it when adding systemctl cat

[Andrei-Pozolotin]

About runtime: Consider or not?

you guys already convinced me that "users should be protected from the advanced cruft", no? :-)

[ml-]

About runtime: Consider or not?

you guys already convinced me that "users should be protected from the advanced cruft", no? :-)

Ok, no runtime changes then.

[Andrei-Pozolotin]

@ml- @dvzrv Guys please confirm if you want to finish this review with a new merge/release. Or not? :-)

@dvzrv David: github wants you to fill out both tag and title https://github.com/random-archer/mkinitcpio-systemd-tool/releases when using Draft a new release, i.e. same version value: v35 for both

[ml-]

@Andrei-Pozolotin Sorry for late response. I will have a look at it and maybe some other things as soon as I have some time.

Need to think about a good setup to quickly test the tool in different environments so I don't break it again.

[Andrei-Pozolotin]

@ml- great, thank you.