Re: solving the network-manager-in-gnome problem
On 2012-07-24 08:16:43 +0200, Tollef Fog Heen wrote:
> ]] Vincent Lefevre
>
> > On 2012-07-23 15:55:27 +0200, Tollef Fog Heen wrote:
> > > ]] Vincent Lefevre
> > >
> > > > On 2012-07-23 10:21:04 +0200, Tollef Fog Heen wrote:
> > > > > ]] Vincent Lefevre
> > > > >
> > > > > > OK, if Debian plans to support other init systems, that's fine.
> > > > >
> > > > > It already does.
> > > >
> > > > Not really, or at least not in a nice way, because sysvinit is
> > > > an essential package.
> > >
> > > How is that relevant? Don't we support pax just because tar is
> > > essential?
> >
> > But installing pax won't remove tar, while...
>
> I don't think it follows at all that because there are init systems
> which conflict with sysvinit, Debian does not support multiple init
> systems.
But in such a case, sysvinit shouldn't be an essential package (and
packages that need it should thus have an explicit dependency on it),
since it isn't really needed in a working Debian system. Otherwise,
if the user wants to use an init system that conflicts with sysvinit,
how do you know that he will not break his system (even if the new
init system is correctly configured)?
> > OK, the package description of systemd by mentioning the rcN.d links.
> > I had the impression they were still used.
>
> They are, unless there are native service descriptions shipped.
If the package description had said that, it would have been
less confusing. It's strange for a package description to focus
on non-native features!
> > Also, it seems that to disable a daemon using systemd units, one needs
> > these native files. But many packages don't provide them. So, real
> > systemd support isn't really there.
>
> You said «I don't see any init system that provides the same feature as
> ENABLE/DISABLE (i.e. together with other configuration options of the
> service, such as the port on which the daemon will listen).», you did
> not specify «without changing anything in the existing packages» og
> something similar.
Well, that was quite obvious to me. By init system support, I mean
that the init system should be provided as packages *and* that
packages providing a service should support the init system natively
(otherwise there isn't much point to switch to another init system).
> Also, to turn your argument on the head: many packages does not provide
> NO_START=1 in /etc/default, so real support for that isn't really there
> either. On my system, it's about 8 of 103 init scripts, which is
> slightly higher than the ratio of packages shipping systemd service
> descriptions to packages shipping init scripts. (58 / 1106 for .service
> files)
The only package for which I want to control whether the daemon is run
or not has such a switch (this is wicd-daemon). I don't (currently)
mind about the other packages. I just don't want this switch to
disappear, or wicd-daemon should provide a native systemd file to
start the daemon (which is not the case currently).
IMHO, for packages that provide such a switch, there should be no
requirement to abandon it without supporting the other init systems
first.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: