On Thu, 07 Sep 2000, Craig Sanders wrote: > On Mon, Sep 04, 2000 at 10:28:20AM -0300, Henrique M Holschuh wrote: > > I was going to tack this sooner or later (the "trust us, we KNOW you > > want the daemons to start always" current state of almost all daemon > > packages annoys me to no end, and from past flamewars I know I'm not > > the only one), I think I even warned a few newbies in -user two days > > ago about this :-) > > it is a reasonable assumption to make - if someone installs a package
Yes, it is. But it is just that: an assumption. That's all we can do right now for package installs, and it CAN be argued that it's all we should ever do in package installs. My current issue is with package upgrades. So, please, let's not even get into the 'start daemons at package install' issue right now. Let me tack the upgrade problem first, and when that's done and ready (please note I didn't say "accepted"), we can move to the install problem and we can argue all you want about it. Here is what I'm trying to fix: Upgrading a daemon while the system is in runlevel 4 and the init script system is set up to stop that daemon in runlevel 4 is a *bug*. If you call the script which addresses the upgrade issue during installs as well, it won't malfunction (this is a design requirement), and you can share the same code for upgrades and installs. It *could* be used to avoid starting a daemon during installs if extended to do so, but it doesn't _have_ to. > > The solution is to *force* all daemon packages to never start a daemon > > out of its intended runlevel, be it during first install or upgrades > > (I think this probably requires a policy change). I'd even say this > > should be a goal for woody, unless we're going to try to get woody out > > of the door very fast. > > this sounds bloody annoying. If everyone had to write a lot of complicated code to get this to work, I'd agree with you. As it stands, I'm writing all the code needed for sysvinit, and I could even try to do the same for file-rc after the sysvinit code is ready, tested, published to -devel and ripped to shreds. A *design* goal in this stuff is that: If you do nothing to the defaults, the system will act just like it does today. In *all* cases, even the highly unlikely ones such as no init system at all being installed. You as a maintainer will have to add something that boils down to: ... update-rc.d foo bar foobar barfoo +if canIstartTheDaemonPlease daemonname; then + /etc/init.d/daemoname start +fi ... After all error checking is stripped off. > if you don't want a service to start, then don't install the package. > simple, really. As I said, let's leave that issue alone for now, please. [...] > no package manager can read your mind. you're still going to have to do It doesn't need to, I consider the start on upgrade as it stands a bug because the system can detect what it should do, unless I am overlooking something... which is why I'm trying to get the code done and working before posting anything else to -devel. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
pgpT619SC1RjZ.pgp
Description: PGP signature
