Re: Packages should not Conflict on the basis of duplicate functionality
As a user, I have to say that the "Provides/Conflicts" that happens
with POP3 servers is annoying.
I wanted to look at each of ipopd, gnu-pop3d and cucipop. I could only
look at one at a time. It was ok in my case, because the machine I was
using has very little pop3 traffic. But it was awkward.
If I wanted to download source and recompile it, I would not be using
Debian. I like the package manager. I also like the thought that goes
into problems like this.
I'd like to see something like this:
WARNING:
you already have a pop3-server installed (cucipop)
starting ipopd automatically may cause problems
there are cases where running several pop3-servers
automatically makes sense: most of them require you to do
special configuration.
if you answer No to the following question, you can edit
"some configuration file", then run "some reconfiguration
program" to start ipopd without conflicting with the existing
pop3-server. Read /usr/share/doc/ipopd/somedocfile
for instructions on how to do this.
do you want ipopd to start automatically? (y/N)
WARNING:
you already have an http-server installed (apache)
starting apache-ssl automatically may cause problems
there are cases where running several http-servers
automatically makes sense: most of them require you to do
special configuration.
if you answer No to the following question, you can edit
/etc/apache-ssl/httpd.conf, then run "some reconfiguration
program" to start apache-ssl without conflicting with the
existing http-server. Read /usr/share/doc/apache-ssl/somedocfile
for instructions on how to do this.
do you want apache-ssl to start automatically? (y/N)
I am full aware that this doesn't solve all the problems. Some
services start from init.d scripts, some from inetd.
pop3 servers seem to mostly run from inetd. But someone may package
one that starts from an init.d script.
Sometimes, different protocols use the same port (ssh and ssh2 come to
mind) In the ssh case, one solution is to enable the "ssh1
compatibility" in the sshd2 configuration. Another is to run ssh1 or
ssh2 on a different port.
Pretty soon, there will be two DNS servers: some people will want to
run Bind as their main server, and test the new one on perhaps just one
IP address. A "Provides/Conflicts" in this case would (for me) really
really suck.
This is a problem that each person who packages a service that listens
on a port has to deal with. And more of a problem because different
implementations of such a service are packaged by different people.
Perhaps a general framework for dealing with the issue would help, if
it left room for each packager to handle things as the package
requires.
The following presumes that each package that provides a service will
provide a virtual package, "service-server", so that the potential
conflict can be detected and dealt with, and that when such a conflict
is detected, a nice long question is asked of the user, and the user
answers yes or no (with no being the default).
Something like:
if it starts from an init.d script, have the init.d script check for
the
existence of some configuration file. based on the content or
existence
of that file, start or don't start the service, configured as
appropriate.
if the user answers no to the auto-start question, make sure the
special
file is in the state which prevents the service from starting. provide
also a script in /usr/sbin to let the user turn on and off the
service,
and/or provide a document in /usr/share/doc/package which describes
how to do it (the document should exist, whether the script does or
not).
if it starts from /etc/inetd, put a line into /etc/inetd which would
start
the service, but commented out if the service should not be started by
default. in this case, the user will probably have to edit
/etc/services
and /etc/inetd to get the service started with no conflict. provide a
document in /usr/share/doc/package which describes how to do it. (i
omitted the script here because it seems to be taboo to edit
/etc/services
from any package except that which owns it)
I'm going to look at ipopd, gnu-pop3d, cucipop, apache, apache-ssl, ssh
and ssh2 to see how bad my idea is. I'll post what I find out.
If a framework like this makes sense, then no package has to know about
another package, and no packager has to know what another packager is
doing, so long as each package and packager "does the right thing" when
a potential conflict crops up.
The bottom line: let the user decide.
Eric
Bestnet Internet Inc
On Fri, 1 Oct 1999 10:28:03 +1000, Craig Sanders wrote:
>On Thu, Sep 30, 1999 at 08:34:48AM -0400, Raul Miller wrote:
>> On Thu, Sep 30, 1999 at 02:16:31PM +1000, Craig Sanders wrote:
>> > to paraphrase: i am against messing with the current default. i am not
>> > against (indeed, i am in favour of) increasing choice.
>>
>> There is currently no default -- it varies on a per-package basis.
>
>update-inetd and update-rc.d pretty much establish what the current
>default is. they are there to be used by the {pre,post}{inst,rm} to
>enable and disable services at install/remove time.
>
>craig
>
>--
>craig sanders
>--
>To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: