Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, Nov 5, 2013 at 2:02 PM, Russ Allbery <rra@debian.org> wrote:
> Peter Dolding <oiaohm@gmail.com> writes:
>
>> ExecStartPre=, ExecStartPost= can be written many times.
>
>> ExecStartPre= rm somewhere
>> ExecStartPre= touch somewhere
>
> That really doesn't help, because...
>
>> In fact lot of cases I see one line entries in systemd and I see bad
>> form. Unless one line has like if or for statements its really bad
>> form inside systemd.
>
> ...of this. If you can't write the scripts with proper block structure,
> it's actually better to just externalize them in a separate file rather
> than doing something this awful to try to inline them.
>
> I don't think you're going to convince me to like this syntax. :) But
> it's a minor issue.
The multi line option in systemd has other uses when debuging.
>
>> Basically upstart is lacking one key feature. If it not fixed it will
>> come back and bite us. Really I would like to see this fixed before
>> debian takes up upstart if debian takes up upstart at all.
>
> I'm afraid there is little chance you will manage to convince me that this
> is a key feature. I've been writing portable shell scripts for years, and
> Debian has been dealing with shell portability issues for years.
> Regardless of what we do with the init system, we will still have to deal
> with this with maintainer scripts, etc. I do see why you're concerned,
> but I just don't see this as critical compared to other issues under
> discussion.
>
Russ I take it from this point of view. If we cannot get a minor key
feature for future compatibly taken upstream. Will means the upstart
maintainer ship has to be classed as proven hostile. This is in fact
a good test to see what init systems Debian can work with to see if
debian can get minor alterations upstream. At this point upstart
maintainer-ship is suspected of being possibly hostile. Its about
time we find out if they are.
As you say we have to deal with maintainers scripts. We also have to
deal with third party items at times. Basically upstart is tieing
one of my hands behind my back to deal with bad upstart files. The
worst risk is ubuntu and debian using a different /bin/sh and having
different portability requirements and I am for some reason forced to
use a ubuntu .deb package for something. Remember the case of steam
binaries. History tells us that your idea we can write script
portable is a foolish idea. Just because you can not everyone else
can. Like if I have altered a script from some third party they can
blame my alteration. Yes there is a reason why you must be able to
just change the shell.
This is not exactly a minor issue. The lack of means to set shell
effects future possibilities of importing binaries built only for
Ubuntu and other distributions using upstart.
Also upstart means writing a more complex auditing tool. Vastly more
complex. Systemd single line system is really simple to write a
script to go through and check everything starting exec after the =
for ; so finding where any maintainer gets the idea of in-lining
foolishly. So is fairly simple to automated a debian test to badly
designed systemd unit files. Yes the external shell script files
will audit with debians existing tools without modifications.
Peter Dolding
Reply to: