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

Re: upstart: please update to latest upstream version



On Fri, Feb 24, 2012 at 10:45:41AM +0000, Lars Wirzenius wrote:
> On Fri, Feb 24, 2012 at 10:51:23AM +0100, Svante Signell wrote:
> > Then you are excluding all non-linux systems. Is that part of Debian
> > policy? While at the time supporting non-linux systems (like kFreeBSD
> > and Hurd, and others to come)
> 
> It is an interesting question, that we should perhaps re-visit at
> this time: to what extent should the desire to support non-Linux
> kernels be allowed to hold back improvements in the GNU/Linux flavor
> of Debian?
> …
> Should we allow kFreeBSD and Hurd (and, possibly, other kernels in
> the future), which do not support the features required by systemd
> and upstart, allow us to get away from sysvinit and start using an
> event based init system?
> …
> The ideal solution would be for Hurd and kFreeBSD to add support
> for systemd and upstart, but I guess that's not so easy. It would,
> however, mean that the work would be done by the people who most
> benefit from it, rather than putting it on the people who probably
> never even use the other kernels.

I certainly don't think it's fair for fairly niche platforms to hold
back Linux indefinitely.  There is a high cost on maintainers to
support these platforms, and it would be an ideal situation if
systemd or upstart were sufficiently portable to run on them, even
if they didn't support all the Linux-specific features they offer
[note: it's somewhat desirable for them to be optional on Linux
too, to prevent feature lock-in and future compatibility problems].

There's nothing intrinsically non-portable about the systemd
socket-based activation scheme.  It's just all the cgroups and other
stuff on top of that that's the problem.  And the attitude of the
upstream maintainer towards portability.  Has anyone investigated
exactly how hard it would be to port?  If it's reasonably simple,
we could just carry those patches in Debian.

Another alternative is to let sysvinit run systemd units and/or
upstart jobs.  Given their declarative syntax, would it be possible
for these to be translated into init script form so that they can
be run by init?  This would provide a migration path and permit
packages to migrate away from providing init scripts in favour of
systemd units (or upstart jobs), while permitting sysvinit use to
continue.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


Reply to: