Lennart Poettering

hmpf, I really don't like this approach. I hate config options which totally redefine what things mean. In particular as some distris will just set this and others won't and...

> This would require a new API, and all applications to buy into that new API. No, it does not. Because I suggested the new flag if not configured specifically...

> It doesn't really redefine it, it makes it stricter, to cover some extra corner cases. The protocol, meaning, tooling, etc are the same. We got tons of options that...

> That would break backward compatibility So would your change. Sorry, I am not convinced that inhibitor semantics should be up for configuration of the admin. I think a more...

> No, as it's disabled by default. yeah, that's even worse: you add something that has different meanings on different systems. That's just bad. You are not going to convince...

> It makes sense just as it makes sense to add flags to make other things more restrictive or change their behaviour, like we do in twenty million other places....

> The relationship is the blocking mechanism. Instead of hiding away systemctl and the rest and replacing with custom scripts, an inhibitor can be used. The frontend to that is...

> Why are you saying "completely redefine"? Nothing is "redefined". It's the same interface, that does the same thing, in the same way. It's made stricter if you want it...

please don't drop the "needs-discussion" label as long as there's no agreement that this is desirable.

> Exactly, that's the problem: instead of using something sensible, it displaces away (and breaks for several obvious reasons) other package's binaries, which is just bad, unless you suddenly became...