| 1 |
I'll start answering from the last point since it explains |
| 2 |
the remaining answers. Sorry for the shuffle. |
| 3 |
|
| 4 |
On Tue, 14 May 2013 10:41:27 +0200 |
| 5 |
Luca Barbato <lu_zero@g.o> wrote: |
| 6 |
|
| 7 |
> On 05/10/2013 09:45 AM, Ralph Sennhauser wrote: |
| 8 |
> > [1] http://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files |
| 9 |
> |
| 10 |
> In the end initscripts are usually distribution dependent since they are |
| 11 |
> an integration step. |
| 12 |
|
| 13 |
Integration? What kind of integration? The kind of integration which |
| 14 |
results in various apps behaving differently depending on the patch set |
| 15 |
used by distro? |
| 16 |
|
| 17 |
The kind of integration which makes performing *simple* administrative |
| 18 |
tasks completely distro-dependant? Seriously, I don't remember anymore how |
| 19 |
to enable services on openrc. And I don't want to get back to the point |
| 20 |
when approach a computer with Arch required me to find out how the necessary |
| 21 |
tools are named there. |
| 22 |
|
| 23 |
That said, Gentoo init.d scripts are an aberration. Either they |
| 24 |
resemble poor hacks to change application behavior, provide additional |
| 25 |
configuration or setup. Isn't init script supposed to *start* |
| 26 |
an application? |
| 27 |
|
| 28 |
When init scripts start to source additional code from external files, |
| 29 |
poorly parse configuration files and reset databases, I believe we |
| 30 |
reached the point of 'done seriously wrong'. And someone mentioned that |
| 31 |
automatic restart of service is dangerous... |
| 32 |
|
| 33 |
> What if openrc/upstart/runit devs start harassing upstream in the same way? |
| 34 |
> |
| 35 |
> Strategically is great, but isn't exactly something nice to do. |
| 36 |
> |
| 37 |
> Probably people caring about alternatives should start bothering |
| 38 |
> upstreams likewise and we'll see how it goes. |
| 39 |
|
| 40 |
Strategically? So we're now at war? Yes, I've noticed the few people |
| 41 |
fancying a pile of hacks complaining about the 'so-wrong' systemd |
| 42 |
breaking the unwritten rules of having a distro-specific pile of hacks |
| 43 |
and trying to improve something for the sake of uniformity. |
| 44 |
|
| 45 |
The point is that openrc/upstart/runit devs never cared enough. Maybe |
| 46 |
they fancied their total control over init scripts or didn't feel |
| 47 |
influential enough, I don't know. |
| 48 |
|
| 49 |
Now that we have something that actually was designed with that point |
| 50 |
in consideration, we have crybabies shouting 'but please use my init.d |
| 51 |
instead! it's so much better because i used it'. The major difference |
| 52 |
would be that systemd is something new, not just the pile of hacks that |
| 53 |
has grown a lot of functionality over time. |
| 54 |
|
| 55 |
> I'm sure that *everybody* would be delighted to provide those 4-5 |
| 56 |
> different initscripts because one distribution or the other wants others |
| 57 |
> do the work for them... |
| 58 |
|
| 59 |
Does it really? I more feel like it specifically doesn't want others to |
| 60 |
touch their precious init scripts. |
| 61 |
|
| 62 |
> I'm saying again that trying to get a good intermediate representation |
| 63 |
> and have a generator (eselect based maybe) provide the init-specific |
| 64 |
> file would be much better. |
| 65 |
|
| 66 |
Did you see how systemd unit files look like? What kind of intermediate |
| 67 |
representation do you want? I don't expect service descriptions to go |
| 68 |
much simpler than this. |
| 69 |
|
| 70 |
Of course, you could just mangle the names, change the format. Do that |
| 71 |
for the sake of making things harder for others. Show how offended you |
| 72 |
are by others not wanting your fancy init.d! |
| 73 |
|
| 74 |
And eselect, of course. Another distro-specific pile of hacks which |
| 75 |
doesn't do anything specific. I wonder if we will have to wait for |
| 76 |
Fedora to replace it. |
| 77 |
|
| 78 |
-- |
| 79 |
Best regards, |
| 80 |
Michał Górny |
Archives