Re: suggested virtual package name: dns-server
Hi,
On Thu, Jan 09, 2003 at 02:50:26PM -0600, Steve Greenland wrote:
> > On Thu, 2003-01-09 at 18:25, Toni Mueller wrote:
> > > I'm stumbling across a load of dns server software that conflict in
> > > imho spurious ways with each other.
> Spurious is exactly the right word to use, and the answer is not to have
> a dns-server virtual package to conflict with, but instead remove the
> conflicts.
point taken.
Resolving the conflicts could well mean to maybe not conflict, but to
provide, a certain functionality in the form of a virtual package.
Letting the idea of the virtual package aside for a moment, what then
constitutes a need for a dependency or a conflict? Or asked another
way, when do packagers install a dependency or a conflict? Apart from
obvious reasons like the need for a certain library (in the case of a
dependency), these seem to be mostly laid out according to taste, or
to "the most common (expected) usage by the average user", not the
people who know how and where to bend everything to their wishes.
Going after the most common case and making it easier for
not-so-experienced users imho warrants having a conflict, but
wanting the packages to co-exist on one system asks for the use of
alternatives, so that eg. /usr/sbin/sendmail points to sendmail's V8,
exim, and postfix' mail injection program in turn, like choosing this
or that vi clone to be the preferred one over the other five which
are also installed. Only that subsystems like mail and dns are much
more complex than that just in terms of operations.
> If the only reason they conflict is because they have the
> potential to listen on the same port, then they should NOT conflict. As
> someone else pointed out, most can be configured to listen on different
> ports, or different addresses, or both.
Nevertheless, all MTAs conflict with each other, probably because the
skill required to run two of them on one box is too far above average.
> OTOH, if they conflict for other reasons (such as using the same binary
> name or configuration files - I suppose bind and bind9 might fall
> into this category), then they need to explicitly conflict with those
> packages that actually cause a problem.
Sorry, but I disagree. It is currently the case that both packages
contain files that are also in the other package, but this is not
a must. Adding one or the other configuration option or adjusting
the build process a little bit should remove these conflicts.
apache and apache2 have it, too, with a binary name of 'apache'
and 'apache2', respectively (instead of the standard 'httpd').
I think that bind vs. bind9 is a particularly ill suited example for
config files since both binds can use most of the other's config
files. Keeping your setup unchanged across different implementations
of "the same" subsystems is no feature inherent in any of the other
packages I'm aware of.
Best,
--Toni++
Reply to: