In the future? Yeah, probably.
This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. Really, I think all of the reasons why systemd attracts hate can be boiled down to this. Nobody wants a standard init system that's overtly hostile to bug reports and reasonable changes.
Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
This. It doesn't help this guy's case that he's basically calling anyone who doesn't want systemd a "troll". That's not the way to win people to your side of a disagreement.
This. Backed by nothing, calling the systemd team "notoriously hard to get along with". I'd be interested in seeing proof of "this".
"The only way to deal with journal corruptions, currently, is to ignore them: when a corruption is detected, journald will rename the file to <something>.journal~, and journalctl will try to do its best reading it. Actually fixing journal corruptions is a hard job, and it seems unlikely that it will be implemented in the near future."
A major bug is reported, and their response is "it's too hard so we won't fix it" in a project that is soon to be at the core of every major GNU/Linux distro? No thanks.
But that's a lot to overcome.
For instance, openssh-client depends on libgssapi-krb5-2 and libselinux1, but neither of those packages have a dependency on the Kerberos 5 userspace clients or on SELinux being configured or enabled, respectively. If you happen to install Kerberos or enable SELinux, then openssh-client will work fine without a recompile (because Debian doesn't have USE flags). If you don't, the libraries will just do nothing. I think SELinux is a terrible and misguided idea that subverts the UNIX philosophy, adds needless complexity, and also doesn't work, but I have no objection to libselinux1 being installed.
Same thing with bsdutils and libsystemd0. The discussion has never been about being "without systemd code" as if it were a noxious poison. (It's free software, I would _hope_ people incorporate good code from it into other packages.) It's about being without systemd, the init system, and if bsdutils did depend on a particular init system, it would be flagrantly in violation of the Technical Committee resolution.
When was Linux or GNU following the Unix philosophy? Can you name a figurehead who says it ever did?
That can only happen if the dbus executables are installed; libdbus-1-3 Recommends but does not Depend on dbus. This is the standard way of things for everything in Debian, and the dbus packaging is no different from the Kerberos packaging here.
As I mentioned, it would be in violation of the tech-ctte ruling if depending on libsystemd0 also brought in systemd itself as a hard dependency.
> it's a reasonable concern to have.
The entire worldview of systemd is that you shouldn't be spawning things from your current environment (cf. daemonizing in /etc/init.d/foo), you should ask some parent keeper process to spawn the executable. It sounds like it would involve systemd doing the exact opposite of what it currently does if libsystemd were to fork-and-exec much of anything.
For instance, systemd is obsoleting the setuid dbus-daemon-launch-helper, which I am super excited about, having gotten on dbus-daemon-launch-helper's bad side far too many times.
It's almost as if systemd was being forced upon you no matter what.
You don't have to. Someone apparently implemented the logind interface(!) so that GNOME could function on non-systemd systems. Just use that.
> This wouldn't be an issue if the systemd people weren't notoriously hard to get along with. [...]
Are you kidding? I've been following along the mailing list for at least two years and I've never seen any of the unreasonableness you claim. (I'm not in any way connected or invested in the systemd project, just as a little disclaimer.)
If you're going to pull this stunt please at least give us concrete references.
> Say what you want about upstart and sysvinit, but I don't recall a point where the maintainers of it were told off for hijacking kernel flags...
Ah, I see. You're just another troll recycling talking points. Oh, well.
Oh, and btw: Complain all you want -- in F/OSS the people doing the work get to decide. Deal.
It'll only grow, though. Most certainly.
Only up to a point. Systemd is getting too bloated, and software engineering tells us that the effort to maintain this will grow exponentially.
So we have two options: if systemd improves and decides to follow UNIX principles, good. Otherwise it'll be replaced like consolekit et al. It's great that we have so many init systems to choose from. The only problem now is software that hard depends on systemd when a single line of code could avoid that.