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
packages.
(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
>
--
Regards,
Dimitri.
Reply to: