User Survey

[martin f krafft]

also sprach Clément Stenac <zorglub at debian.org> [2006.09.03.1148 +0200]:
> Should it be simply removed, or should a virtual "init" package be
> created with sysvinit and upstart providing it ?

rdepends:
ii  bluez-utils    3.1-4          Bluetooth tools and daemons
ii  console-tools  0.2.3dbs-64    Linux console and font utilities
ii  dpkg           1.13.22        package maintenance system for Debian
ii  e2fsprogs      1.39-1         ext2 file system utilities and libraries
ii  initscripts    2.86.ds1-15    Scripts for initializing and shutting down t
ii  initscripts    2.86.ds1-15    Scripts for initializing and shutting down t
un  kbd            <none>         (no description available)
un  lm-sensors     <none>         (no description available)
pn  modutils       <none>         (no description available)
un  nfs-common     <none>         (no description available)
un  nis            <none>         (no description available)
un  sysv-rc-conf   <none>         (no description available)

If you ask me, none of these need to depend on init.

un  file-rc        <none>         (no description available)
ii  sysv-rc        2.86.ds1-15    System-V-like runlevel change mechanism

But these do. A virtual package would be the clean solution.



also sprach Clément Stenac <zorglub at diwi.org> [2006.09.03.1848 +0200]:
> > Define "diverging" ... we're changing init! that's a pretty big,
> > whopping divergence for a start.  It's obviously going to have
> > knock-on effects on everything else.
> 
> Actually, it can be seen as "providing another init, and, in this
> goal, making sure that init can be changed".

I agree. We're not changing init, we're providing an alternative.
Ubuntu chooses to make this alternative the default. If we care
about Debian, this won't happen for a while, but it would be nice to
have the alternative.



also sprach Scott James Remnant <scott at netsplit.com> [2006.09.03.1855 +0200]:
> That's correct.  Upstart isn't a dependency-based init system, unlike
> initng, it works purely on events.  The principal difference is that
> it's backwards.  A dependency-based init system starts network because
> apache depends on it, an event-based init system starts apache because
> network has been started.

That's forwards. :)

> > But how will upstart handle things like "apache needs network to be set
> > up"
> > 
> "start on network" ?
> 
> > "tomcat needs postgresql to be up"
> > 
> "start on postgresql" ?

What about "needs network and postgresql", assuming postgresql does
not need network?



also sprach Scott James Remnant <scott at netsplit.com> [2006.09.03.1847 +0200]:
> The following packages had legacy dependencies on sysvinit (due to some
> invoke/update-rc.d change years ago) removed:

So we could just remove these dependencies in Debian, no?

> > I am not talking about now and here, and would be perfectly happy to
> > aim for post-etch.
> > 
> Ok, does that mean you want to delay any work on upstart in Debian for
> post-etch?

No; target experimental for now.

> I still think that an interim archive would be an idea.  Perhaps someone
> would like to set one up?  Marco?

What's the purpose of an interim archive?

> > > Of course, if those obstacles can be overcome, there's also no
> > > reason it couldn't be developed "in Ubuntu" and sync'd into
> > > Debian.
> > 
> > No. Though doing it this way seems the wrong way around to me. Maybe
> > that's just me.
> > 
> *shrug* either way, this is just playing politics at the moment -- which
> seems rather childish.

No, actually it has nothing to do with politics.

I realise Ubuntu is going to diverge and become independent of
Debian, at which point I'll be on my own and you're going to be
upstart upstream to me.

Until Ubuntu has officially declared independence, Debian will be
the slower-moving distro, and you've illustrated how things work
yourself:

http://www.netsplit.com/blog/work/canonical/ubuntu_and_debian.html

> I asked you to package upstart for Debian because in the past
> you've expressed both an interest in init, and you've also
> expressed an interest in helping ensure that work done in Ubuntu
> makes it into Debian.
> 
> Frankly turning around, throwing your toys out of the pram, and
> claiming that the work should be done in Debian in the first place
> was not the response I expected from you.  You know better than
> that.

I was voicing my opinion. That was not supposed to be flamebait.
I also did not realise what of a touchy subject this is. If you're
completely opposed to Debian (have you read [0]?), then of course
I cannot ask you to work with Debian in mind. However, if you're
not, then does it really cost that much to entertain the thought?

0. http://blog.madduck.net/debian/2006.09.03_never-give-up

> I was somewhat hoping you'd be able to lead the way in showing how
> Debian developers can related to Ubuntu developers, and ensure
> that the good work Ubuntu do makes it into Debian -- instead you
> appear to be playing games?

I am trying, Scott. Maybe we should have picked an example that
didn't (a) have the ambitious goal to replace PID 1, and (b) didn't
require libc6 from experimental.

I am also quite loaded with real life. I am very interested, but
I just didn't anticipate how much work upstart would be. I'll stay
on it, I'll try to push the necessary changes in Debian, but I can't
make guarantees. Any bit you can move closer to Debian development
would help me.

-- 
 .''`.   martin f. krafft <madduck at debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
micro$oft is to operating systems & security
what mcdonalds is to gourmet cuisine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20060904/a14051d7/attachment.pgp