On 1/30/20 7:02 AM, Thomas Goirand wrote:
This is normally solved if using pre-depends, which ensure that a
package is configured before using it (and not just unpacked).
Having everything using sysusers have versioned Pre-Depends on systemd |
opensysusers would probably minimize the problem,
On 1/29/20 2:19 PM, Simon McVittie wrote:
I think we have a fairly good picture of the costs that would be
incurred from using alternatives: more interacting code paths to test,
potentially more configurations that are technically possible but are
not considered supported, and packages with "Depe
On Wed, 2020-01-29 at 16:49 +0100, Didier 'OdyX' Raboud wrote:
> We'd first have to agree that an alternative is actually _needed_.
> And so far,
> the only arguments I have read in favour of providing alternatives to
> /bin/systemd-sysusers are:
> * A) it is shipped in the systemd binary package
--- Begin Message ---
On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote:
>
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on t
On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote:
>
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.
It is as simple as
It's different than awk because the decision the admin is making ("which
init system do I want to run"?) isn't done through alternatives. So you
can't use the alternatives system to coordinate swapping all the
different bits together.
It seems retty reasonable to me that the systemd maintainer
6 matches
Mail list logo