KatolaZ wrote on 19.05.2015 12:55:
> On Tue, May 19, 2015 at 12:42:43PM +0200, Anto wrote:
> [cut]
>> I have never used Slackware but that is similar problem as I have
>> experienced since last year with Debian wheezy. I think the main
>> problem is that, a lot of upstream packages and their maintainers in
>> most distros support systemd. So they intentionally add everything
>> that systemd needs into those packages, *just in case* the users
>> want to use systemd. That *just in case* thinking is what I really
>> hate as it is stupid. And that is because of the systemd developers
>> are just so dumb and idiot to be able to write modular program so
>> that there is no need to change anything on any packages requiring
>> it. Did that happen on sysvinit, upstart, openrc, etc.? If systemd
>> would be modular, I would consider to use it.
>
> I honestly don't see the problem here. If I were the developer of a
> daemon, I would do my best to provide init scripts for all the major
> known init systems my daemon is likely to be working with. Then, we
> can argue about the current unfortunate situation, in which we dislike
> the mainstream init system (systemd), but unfortunately we can't
> ignore the fact that systemd exists, and is probably here to stay for
> a while, since almost major linux distributions have adopted it as a
> default....
>
> I don't see anything wrong in providing an alternate init script,
> indeed, and I won't consider a package "infected" only because it
> provides an init script for an init system that I don't use (or that I
> dislike)....

[KatolaZ, I'm piggybacking your post - hope you don't mind.]

I think you have a point here that cannot be stressed enough. I would
think of a package maintainer providing compatibility with and support
for as many existing init systems as possible as being very considerate
and responsible. Isn't that what the whole "freedom of choice" stance is
all about in the first place?

IMHO, having a few inactive scripts or configuration files lingering
around that are there simply there to provide just-in-case support for
an init system I do not happen to use (or even like, FWIW) is nothing
worth worrying about.

If, OTOH, in contrast an upstream maintainer were to introduce hard
dependencies on any specific init system, disabling or crippling crucial
core functionality of the software when used with any other init system,
that would IMNSHO be a very inconsiderate approach. No matter if that
would rule out systemd, or sysvinit, or any other alternative currently
available.

Just to be clear: Personally, I follow and use Devuan because I prefer
to maintain my installations [as] free [as possible] of any systemd
components, but calling "stupid" the fact that a maintainer takes a more
or less neutral stance WRT to init systems is a bit over the top, I think.

My one-and-a-half cents. ;-)

Cheers,
Urban