On Sat, 06 Mar 2004, Thomas Hood wrote:
> A far superior alternative has been written by Joe Oppegaard
> <[EMAIL PROTECTED]>. He is currently tuning the program and plans to upload
> it very soon under sponsorship.
Quite a few people seem to be satisfied with rcconf, though sysv-rc-conf, the
new
On Wed, Mar 10, 2004 at 12:23:23PM +0100, Thomas Hood wrote:
Upgrades are handled properly if and only if rc symlink farms are
fully populated.
No, they *aren't* handled properly, since they can't cope with manually
started services. It's broken either way. And if you think about it,
we already
On Wed, 2004-03-10 at 00:10, Michael Stone wrote:
> Well, there are long-standing bugs in debian's handling of services on
> upgrade. It wasn't long ago that the system blindly restarted
> everything. Now it guesses, but doesn't do a all-round good job.
Upgrades are handled properly if and only if
On Tue, Mar 09, 2004 at 11:25:03PM +0100, Thomas Hood wrote:
The first problem (as has already been mentioned) is that in the absence
of symlinks the service will be started on upgrade even if it wasn't
running before the upgrade.
Well, there are long-standing bugs in debian's handling of servi
On Tue, 2004-03-09 at 14:28, Michael Stone wrote:
> If a services is never automatically started by any
> runlevel the only way it will be running is if the admin launches it. I
> do this all the time for things I don't want running on an automatic
> basis, but which I might want when I'm testing s
On Tue, 09 Mar 2004, Michael Stone wrote:
> On Tue, Mar 09, 2004 at 09:40:22AM -0300, Henrique de Moraes Holschuh wrote:
> >rcconf should just be fixed to put kill links. "floating" instead of "off"
> >is a bad idea to begin with IMHO, unless you have the three states.
>
> You haven't given an act
On Tue, Mar 09, 2004 at 09:40:22AM -0300, Henrique de Moraes Holschuh wrote:
rcconf should just be fixed to put kill links. "floating" instead of "off"
is a bad idea to begin with IMHO, unless you have the three states.
You haven't given an actual rationale for that but I'll explain why I
think
On Mon, 2004-03-08 at 12:09, Michael Stone wrote:
> On Mon, Mar 08, 2004 at 09:28:05AM +0100, Thomas Hood wrote:
> >The configuration is not interpreted to mean "no-op". As I said
> >before,
>
> you said it, but it's wrong.
>
> >There is evidently a lot of confusion surrounding this issue.
> >So
On Tue, 09 Mar 2004, Thomas Hood wrote:
> On Mon, 2004-03-08 at 16:20, Henrique de Moraes Holschuh wrote:
> > Can we just document this to be "Service state is not modified on runlevel
> > changes involving that runlevel"? At least, that is not a dangerous, nor
> > broken behaviour.
>
> Sorry, I
On Mon, 2004-03-08 at 16:20, Henrique de Moraes Holschuh wrote:
> Can we just document this to be "Service state is not modified on runlevel
> changes involving that runlevel"? At least, that is not a dangerous, nor
> broken behaviour.
Sorry, I don't follow you here. Which documentation? Do you
On Mon, 08 Mar 2004, Michael Stone wrote:
> >There is evidently a lot of confusion surrounding this issue.
> >Something should be added to the Debian Reference about it.
>
> Luckily there's already something in debian policy:
Unfortunately, it is totally useless.
> By default update-rc.d will st
On Mon, 08 Mar 2004, Thomas Hood wrote:
> On Mon, 2004-03-08 at 09:16, Henrique de Moraes Holschuh wrote:
> > In fact, currently invoke-rc.d will refuse
> > to start/restart the service
>
> Actually this is not true.
Indeed it is not. Answering such mails late at night is not wise,
and I should
On Mon, Mar 08, 2004 at 09:28:05AM +0100, Thomas Hood wrote:
The configuration is not interpreted to mean "no-op". As I said
before,
you said it, but it's wrong.
There is evidently a lot of confusion surrounding this issue.
Something should be added to the Debian Reference about it.
Luckil
On Mon, 2004-03-08 at 09:16, Henrique de Moraes Holschuh wrote:
> In fact, currently invoke-rc.d will refuse
> to start/restart the service
Actually this is not true.
[EMAIL PROTECTED]:/etc$ ls -l */*dummy*
-rwxr-xr-x 1 root root19 2004-03-08 09:30 init.d/dummy*
[EMAIL PROTECTED]:/etc$ #
On Sun, 2004-03-07 at 22:55, Michael Stone wrote:
> On Sun, Mar 07, 2004 at 10:14:11PM +0100, Thomas Hood wrote:
> >Argh! You're not supposed to delete _any_ links [...]
> >If there is neither an S nor a K symlink for a service in a
> >runlevel it [...] is a misconfiguration.
>
> no, it's a no-o
<[EMAIL PROTECTED]>
> To: debian-qa@lists.debian.org
> Subject: Re: Please remove rcconf
> Date: Sun, 07 Mar 2004 16:55:53 -0500
>
> On Sun, Mar 07, 2004 at 10:14:11PM +0100, Thomas Hood wrote:
> >Argh! You're not supposed to delete _any_ links -- just rename
> >t
On Sun, Mar 07, 2004 at 10:14:11PM +0100, Thomas Hood wrote:
Argh! You're not supposed to delete _any_ links -- just rename
them from Sn to K(100-n) and back.
No, deleting them would be fine.
If there is neither an S nor a K symlink for a service in a
runlevel it does not mean that the serv
On Sun, 2004-03-07 at 21:09, Michael Stone wrote:
> On Sun, Mar 07, 2004 at 03:05:42PM -0500, Joe Nahmias wrote:
> >No, you're only supposed to delete the start links (S??service), not all
> >the links.
>
> Ah, yes. Deleting *all* the links would be a pretty severe bug.
Argh! You're not supposed
On Sun, Mar 07, 2004 at 03:05:42PM -0500, Joe Nahmias wrote:
No, you're only supposed to delete the start links (S??service), not all
the links.
Ah, yes. Deleting *all* the links would be a pretty severe bug.
Mike Stone
Michael Stone wrote:
> On Sun, Mar 07, 2004 at 06:46:55PM +0100, Thomas Hood wrote:
> >has let it be known that there will be a new release RSN. The
> >big issue (deleting symlinks to disable a service) apparently
> >will remain unfixed in this release but I'll take that up with
>
> Why is that a
On Sun, Mar 07, 2004 at 06:46:55PM +0100, Thomas Hood wrote:
has let it be known that there will be a new release RSN. The
big issue (deleting symlinks to disable a service) apparently
will remain unfixed in this release but I'll take that up with
Why is that a problem? It's how you're *suppos
On Sun, 2004-03-07 at 12:19, Arnaud Vandyck wrote:
> Isn't it a better thing to resolve all the bugs, and maybe make
> a(nother) NMU of the package. And then, remove it *after* the new
> alternative will be in a good shape and in the Debian pool?
It appears that an NMU won't be necessary because t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks for pointing these bugs. I also see you file bugs in the bts. I'm
Cc:ing kamop.
Isn't it a better thing to resolve all the bugs, and maybe make
a(nother) NMU of the package. And then, remove it *after* the new
alternative will be in a good shap
On Sun, 2004-03-07 at 04:06, Ron Murray wrote:
>What problems are you having with this package?
* Missing dependency on sysv-rc
* Totally inadequate documentation
* Displays every file in /etc/init.d/ as a service even if it
ends in .dpkg-old or lacks x permission
* Silently omits services w
On Sat, 2004-03-06 at 03:31, Thomas Hood wrote:
Please remove the rcconf package from Sarge. In my opinion it
is not adequate as a runlevel editor and is not release quality.
It is buggy. The maintainer isn't particularly active. A far
superior alternative has been written by Joe Oppegaard
"R. Wood" <[EMAIL PROTECTED]> writes:
> rcconf has always worked fine for me BTW.
It works really fine for me too
--
.''`.
: :' :rnaud
`. `'
`-
On Sat, Mar 06, 2004 at 02:50:15PM -0500, R. Wood wrote:
On Sat, Mar 06, 2004 at 09:31:59AM +0100, Thomas Hood imagined:
Rcconf checks 'defaults' links in /etc/rc?.d/ directories
for choice as unset, whether the package has the start
file with the same number in /etc/rc?.d/(?:=2345)
On Sat, Mar 06, 2004 at 09:31:59AM +0100, Thomas Hood imagined:
> Please remove the rcconf package from Sarge. In my opinion it
> is not adequate as a runlevel editor and is not release
> quality. It is buggy. The maintainer isn't particularly
> active. A far superior alternative has been writt
On Sat, Mar 06, 2004 at 09:31:59AM +0100, Thomas Hood wrote:
> Please remove the rcconf package from Sarge. In my opinion it
> is not adequate as a runlevel editor and is not release quality.
> It is buggy. The maintainer isn't particularly active. A far
> superior alternative has been written b
29 matches
Mail list logo
