[Pkg-systemd-maintainers] Bug#739814: Bug#739814: [systemd-ui] "on other init script" in extended description

[Filipus Klutiero]

On 2014-02-28 13:14, Michael Biebl wrote:
> clone 739814 -1
> reassign -1 systemd
> thanks
>
> Am 22.02.2014 18:40, schrieb Filipus Klutiero:
>> Package: systemd-ui
>> Version: 3-1
>> Severity: minor
>>
>> The extended description contains:
>>> It also provides process supervision using cgroups and the ability to
>>> not only depend on other init script being started, but also
>>> availability of a given mount point or D-Bus service.
>> The noun phrase "other init script" is missing a determiner (the zero
>> article could be used if "script" was plural). "another init script"
>> might be intended.
>>
>> By the way, the rest of the sentence has the same problem ("but also
>> availability of a given mount point or D-Bus service").
>>
> This paragraph was copied from the systemd package description. Thus
> that bug also exists there.
>
> I think the long package description of systemd could use an update.
> Here's the current one:
>
>   systemd is a replacement for sysvinit.  It is dependency-based and
>   able to read the LSB init script headers in addition to parsing rcN.d
>   links as hints.
>   .
>   It also provides process supervision using cgroups and the ability to
>   not only depend on other init script being started, but also
>   availability of a given mount point or dbus service.
>
>
> It puts a bit too much focus on sysv/LSB compatibility. The second
> paragraph also reads a bit odd.
>
> This is from upstream home page:
>
> systemd is a system and service manager for Linux, compatible with SysV
> and LSB init scripts. systemd provides aggressive parallelization
> capabilities, uses socket and D-Bus activation for starting services,
> offers on-demand starting of daemons, keeps track of processes using
> Linux control groups, supports snapshotting and restoring of the system
> state, maintains mount and automount points and implements an elaborate
> transactional dependency-based service control logic. It can work as a
> drop-in replacement for sysvinit.
>
>
> I like that a bit better and would suggest we just use that in our
> package description.
>
> Comments?
>
>
>

I agree. It prefer it. I suggest grouping all compatibility information in a single sentence at the end:
> It is compatible with SysV and LSB init scripts and can work as a
> drop-in replacement for sysvinit.

-- 
Filipus Klutiero
http://www.philippecloutier.com