[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re-Proposal - preserve freedom of choice of init systems

On 17 October 2014 23:19, Simon Richter <Simon.Richter@hogyros.de> wrote:
> Hi,
> On 17.10.2014 22:13, Ansgar Burchardt wrote:
>> I note that it was *not* possible to switch init systems in Wheezy in a
>> supported way (in particular sysvinit is essential and various things
>> get very unhappy if it gets uninstalled), but you seem to treat Jessie
>> as more problematic even though it allows switching init systems? How
>> come?
> I applaud the possibility to switch init systems.
>> And is "you cannot switch init systems (at all)" to "you cannot
>> switch init systems if you want to run <X>" a regression that takes away
>> choice?
> The regression comes in two forms:
> 1. "a package that is a dependency of a package that is a recommendation
> of a dependency of <X> requires the init system to be <S>".
> This requires manual intervention by the user if they do not want to
> switch init system. My laptop moved to systemd because I installed a
> Japanese input method which uses GTK, which depends on libcolord, which
> recommends colord, which indirectly depends on systemd.

>From multiarch and cross-building point of view library package must
not depend, and should not recommend, equivalent executable / runtime
(Although I can see the reasons behind marking colord m-a:foreign &
libcolord m-a:same with dependencies declared as they are now)

Also I think if "depends" exist one way between two packages, a
reverse "recommends" should not be allowed.

> No part of the chain is wrong. The strong dependencies are libraries in
> DT_NEEDED, so they cannot be easily demoted, and the libcolord -> colord
> recommendation also makes sense. The end result, however, is that
> installation of an application package may require extensive changes to
> the core system or manual intervention by the user, overriding the
> package manager.
> 2. "the init system required to run <X> is mutually exclusive with the
> init system required to run <Y>."
> This is at present purely academic, but I'm not convinced it will remain
> this way. We also ship a desktop environment aimed at less powerful
> hardware, would we be okay if that system used a different network
> configuration subsystem conflicting with systemd?
>  - If yes, what should system administrators wishing to offer their
> users a choice of environment do?
>  - If no, why would it be acceptable for one system to do so, but not
> for the other?
> I'd rather avoid these problems in the first place.
> We have a sensible default in place for desktop users, who are the ones
> in need of a default setting.
> However I believe that systemd is not ideal for server environments
> (where we'd rather have minimal attack surface rather than features) and
> downright unusable for embedded applications where memory is scarce, and
> thus I find it very important that the package manager *never*
> second-guesses my choice of init system because of a dependency.
>    Simon



Reply to: