Re: Packages should not Conflict on the basis of duplicate funct
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 option for
> > obvious reasons)
> > c) first come first serve -- first daemon installed does its job, the rest
> > install unconfigured
> >
> > any others?
>
> d) have something that keeps track of installed services, perhaps with
> priorities akin to alternatives. If there weren't an issue of
> services being run either in inetd or standalone, this could
> be accomplished with a souped-up update-inetd.
a) is possible, but I don't really like it. It may be not too bad if
'prompt' means 'ask debconf'.
d) is perhaps the right thing, but sounds like a lot of work and changes
to dozens of packages.
Until this is done, c) could be a possible solution. It would also allow
to inhibit automatic start of services at all by providing packages
noop-httpd, noop-fingerd, ... (in extra and with appropriate warning in
the description) to be installed as 'first ones' by the knowing sysadmin.
The main problem I see with c) is how to determine if we are the first one
regarding the standalone/inetd mess without introducing parts of d).
c) should the be designed so that it makes later transition to d) easy (in
fact c) could be just one of the policies implemented by d)).
But then decisions on flexibility (how highly-customized and
possibly problematic setups are to be supported: multiple interfaces -
some secure and some not, multiple IPs - virtual hosting etc., ...)
have to be made early or daemon package maintainers will become
badly-behaved daemons themselves.
Some basic ideas for c) -> d) :
/var/state/servicemgr/daemons:
#the supergeneric version, perhaps drop/ignore some fields
#package service interface ip port protocol inetd|standalone mtime
apache www * * 80 tcp standalone 28 Sep 1999 \
18:30:16 -0000
interface and ip would have to be * by default or things will badly suck on
machines without permanent network connection. interface can be determined
by IP most of the time, but not for dial-up connections. fetchmail tries
to care for the right (secure) interface if asked to but is no real
example for the kind of daemon addressed here because it doesn't listen
ports but polls. Are there any?
A package providing a daemon would then have to supply a canonically-named
script or executable, e.g. <package>.dmconf with canonical
options/arguments (including service, because one excutable may provide
several at once) to de/configure and register all that stuff with the help
of some scripts supplied by 'servicemgr'. <package>.dmconf should be
allowed to fail (gracefully) if the setup is more complex than it can
handle (which could include, for a start, interface != *, ip != *,
moving services into/out of inetd.conf, using non-standard ports or
setting up coexistence with another package already providing the same
service so we're back to c)).
The nicest thing would be to make what I called <package>.dmconf a new
kind of maintainer script or include it in one of the existing.
To make things even more complex, the default configuration for the first
or only daemon providing a service should be taken from debconf if one has
been chosen there. This could require that parts of the per-package
configuration are in a cononical format, too if settings of the kind
'whatever httpd I use, I want it on port 81!' should be supported.
Does this mean a) -> d) is the better way of migration?
Bj"orn Brill <brill@fs.math.uni-frankfurt.de>
Frankfurt am Main, Germany
Reply to: