>
> e) Let update-inetd handle this. This might not be enough for standalone
> servers like apache and roxen but it would work with a pop3 server -
> update-inetd -add should notice that there is already a valid entry enable
> with that service and add the new entry with a hash mark.
>
Not enoug
On Tue, Sep 28, 1999 at 02:29:55PM -0400, Clint Adams wrote:
> > Ok, let's bring this back to implementation. How would you propose we
> > handle
> > this? Currently daemons install, set themselves up, and begin running.
> >
> > a) we can prompt.
> > b) we leave everything off and let the admin
> > Ok, let's bring this back to implementation. How would you propose we
> > handle
> > this? Currently daemons install, set themselves up, and begin running.
> d) have something that keeps track of installed services, perhaps with
>priorities akin to alternatives. If there weren't an iss
Seth R Arnold wrote:
> The install program will scan the list of installed programs, and for each
> package that Provides: service, it will offer a choice of which to configure
> by default.
FWIW, debconf will soon be able to do this, though it cannot yet.
--
see shy jo
On Tue, Sep 28, 1999 at 11:13:53AM -0700, Sean 'Shaleh' Perry wrote:
> Ok, let's bring this back to implementation. How would you propose we handle
> this? Currently daemons install, set themselves up, and begin running.
>
> a) we can prompt.
> b) we leave everything off and let the admin turn i
On Tue, 28 Sep 1999, Clint Adams wrote:
> > I'll stick my hand up for option (c). The effort involved in
> > modifiying configurations is marginal.
>
> And by what means does the package determine whether or not
> another package has "gotten there first?"
Try to use whatever resource they want.
> Are they automatically setup [ the 4 auth ports ] or is some manual
> intervention required?
The server to which I referred is runnign FreeBSD. Nothing is automatically
set up.
> I'll stick my hand up for option (c). The effort involved in
> modifiying configurations is marginal.
And by what means does the package determine whether or not
another package has "gotten there first?"
On Tue, 28 Sep 1999, Clint Adams wrote:
> > Ok, let's bring this back to implementation. How would you propose we
> > handle
> > this? Currently daemons install, set themselves up, and begin running.
> >
> > a) we can prompt.
> > b) we leave everything off and let the admin turn it on (not an
On Tue, 28 Sep 1999, Clint Adams wrote:
> > Now I do agree with your initial statement, not all things should conflict.
> > wmcdplay and xmcd both play cd's -- they dont conflict. However a deamon
> > provides a known service that only one should be performing at ALL times.
>
> That is a very n
On Tue, 28 Sep 1999, Sean 'Shaleh' Perry wrote:
>
> Because as everyone knows the last 10% takes 90% of the work and often ends up
> hurting the other 90%.
In this case though I've already seen two simple solutions which won't
hurt anyone except the person doing the `odd' setup ...
> The point
> Ok, let's bring this back to implementation. How would you propose we handle
> this? Currently daemons install, set themselves up, and begin running.
>
> a) we can prompt.
> b) we leave everything off and let the admin turn it on (not an option for
> obvious reasons)
> c) first come first serv
Ok, let's bring this back to implementation. How would you propose we handle
this? Currently daemons install, set themselves up, and begin running.
a) we can prompt.
b) we leave everything off and let the admin turn it on (not an option for
obvious reasons)
c) first come first serve -- first dae
> Because as everyone knows the last 10% takes 90% of the work and often ends up
> hurting the other 90%.
Then it's being done wrong.
> The point is Debian needs to work for as many people as possible. We are
> doing
Yes, that's exactly the point.
> apt-get source qpopper
[...]
> dpkg -i qpop
On 27-Sep-99 Clint Adams wrote:
>> a) I would not test a new daemon on a working machine, I would use a
>> separate
>
> So?
>
>> b) if you know what you are doing, compile the packages by hand, fix their
>> install scripts, and remove the conflicts. You are trying to circumvent the
>> norm.
>
On Mon, 27 Sep 1999, Sean 'Shaleh' Perry wrote:
> b) if you know what you are doing, compile the packages by hand, fix their
> install scripts, and remove the conflicts. You are trying to circumvent the
> norm.
But I think, to be fair, that what he's proposing *isn't* necessarily
`not the norm'
Franklin Belew <[EMAIL PROTECTED]> writes:
> PS: I know my lines are longer than 76 characters, fix your own pager/viewers
> wordwrap
No, fix your attitude and read RFC1855. Excerpt:
- Limit line length to fewer than 65 characters and end a line
with a carriage return.
On Mon, Sep 27, 1999 at 04:44:10PM -0400, Clint Adams wrote:
> > a) I would not test a new daemon on a working machine, I would use a
> > separate
>
> So?
>
> > b) if you know what you are doing, compile the packages by hand, fix their
> > install scripts, and remove the conflicts. You are tryi
> a) I would not test a new daemon on a working machine, I would use a separate
So?
> b) if you know what you are doing, compile the packages by hand, fix their
> install scripts, and remove the conflicts. You are trying to circumvent the
> norm.
If I wanted to compile them by hand, why would I
>
> So what you're telling me is that anyone with a "complex" setup
> shouldn't bother using Debian?
>
a) I would not test a new daemon on a working machine, I would use a separate
one. In the case of gnu pop3, it will spin off and consume 99% of your cpu due
to poor child management. We (I am
20 matches
Mail list logo
