[systemd-devel] [HEADS-UP] Packaging systemd

[David Zeuthen]

Hi again,

On Wed, Jul 7, 2010 at 7:27 AM, David Zeuthen <zeuthen at gmail.com> wrote:
> Hi Lennart,
>
> On Sat, Jul 3, 2010 at 9:16 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
>> On Fri, 25.06.10 03:14, Michael Biebl (mbiebl at gmail.com) wrote:
>>
>>>
>>> 2010/6/25 Kay Sievers <kay.sievers at vrfy.org>:
>>> >
>>> > and converted udev init scripts to native systemd configurations to
>>> > place into /lib/systemd/system/ are here:
>>> >  http://people.freedesktop.org/~kay/systemd/
>>>
>>> Looking at the udev.service file, I noticed:
>>> [Service]
>>> Type=notify
>>> ExecStart=/sbin/udevd
>>> ExecStartPost=/sbin/udevadm trigger --type=subsystems --action=add
>>> ExecStartPost=/sbin/udevadm trigger --type=devices --action=add
>>>
>>> That duplicate ExecStartPost, is that a bug or intentional? If the
>>> latter, what is the order in which those commands are run?
>>> Is it possible to run other Exec* commands, like ExecStart= in
>>> parallel/multiple times?
>>
>> Intentional. They are executed one after the other, serially. If you
>> want parallelization, use multiple service files.
>
> Interesting. So one one hand, you're saying "we're using the a
> Desktop-file format because there's so many parsers / API for it", yet
> with this move you break compatibility with a lot of them (in
> particular GKeyFile [1]). Embrace and extend? Anyway, it's a bit too
> clever... and, without getting all emotional... a bit inconsiderate
> for my taste. Not that I'm super-invested in this (I'm not planning to
> parse any of these files myself, anyway), but, any chance you can
> figure out a better way to do this? Thanks!

In fact, turns out that valid desktop-files must not have multiple
keys with the same name; from
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html

  Multiple keys in the same group may not have the same name.
  Keys in different groups may have the same name.

OK, so you actually said "closely follows"

  The native configuration files use a syntax that closely follows the
well-known
  .desktop files. It is a simple syntax for which parsers exist already in many
  software frameworks. Also, this allows us to rely on existing tools for
  i18n for service descriptions, and similar. Administrators and developers
  don't need to learn a new syntax.

Still, I think it might be nice to actually make it easy for GKeyFile
and other software to use your configuration files. Anyway, I'm not
terribly invested in this.

     David