On 17 October 2014 23:19, Simon Richter <simon.rich...@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. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/canbhlujqi9ikrux7nuk_tcwsy0vjsu8vzy5lnc5etef2uz8...@mail.gmail.com
