Re: suggested virtual package name: dns-server
On 10-Jan-03, 11:52 (CST), Toni Mueller <toni@debian.org> wrote:
> I also feel free to note that you and I, at least, are talking
> about different things, or that you seem to have misunderstood
> what I have tried to say in, as it seems, a confusing way.
Let's split up the issues, as I see it:
1. Should various DNS packages conflict?
2. Is a dns-server virtual package the appropriate way to express
conflicts?
(If those aren't the issues, then you're right, I'm confused.)
I think we agree that the answer to #1 is no, there is no technical
reason that *all* the DNS packages need to conflict; in general they do
not share the same filename space or configuration files. By default,
they all use the same port, but while changing the port number is pretty
useless, running multiple IP interfaces is not uncommon. OTOH, there may
be reasons for individual instances of DNS packages to conflict, but
these need to be expressed on an individual package basis, just like
most conflicts. Therefore, that implies that the answer to #2 is also
no, a virtual package for dns-server does not provide a useful purpose.
> > On 09-Jan-03, 15:55 (CST), Toni Mueller <toni@debian.org> wrote:
>
> I strongly disagree with this assessment. You are apparently jumping
> to a conclusion on the wrong track, so please let me put the point
> forward again.
I was trying to explain *why* these various mechanisms exist.
> It was aimed at the political reasons on when to declare a conflict
> because one could imagine to have eg. the vim package -not- provide
> /usr/bin/vi
Sure, but that's not as useful.
> and thus remove that conflicting item (didn't check
> if there are other namespace clashes). Or for sendmail/exim: The
> exim package could likely be crafted in a way to not provide
> /usr/sbin/sendmail.
And thus become pretty much useless, at least so far as sending local
mail.
> Not that that's
> a desirable course of action, but the dns packages I've encountered
> so far don't seem to all provide /usr/sbin/named, for example, and
> still they conflict.
They shouldn't.
>
> > A Conflict exists when two packages cannot be installed on the system
> > at the same time.
>
> Having such a conflict is largely a political decision, imho.
No, it's technical -- but not black and white. It says that the
disadvantage of not being able to install both (all) of the affected
packages is out-weighed by the effort and awkwardness of supporting
simultaneous installation. Those are technical decisions by the package
maintainers.
> All halfway-decent software, and at least all that comes with source,
> can be bent in a way to avoid such namespace clashes.
Of course. But there's little value in having an awk interpeter called
/usr/bin/my_little_awk. Or, more relavently, I can modify my syslogd
substitute to listen on something besides /dev/log, but it's not very
useful.
> The question is the rationale when to leave a possible conflict in,
> or when to declare one even if no files from other packages will
> be overwritten.
yes.
>
> > alternative system was created. Note that this is on a *file* level, and
> > has nothing to do with dependencies.
>
> Well, it _has_ to do with dependencies. If you want both vim and nvi
> provide /usr/bin/vi, then you need to either declare a conflict in
> order to prevent one package overwriting the other's /usr/bin/vi,
> or use the alternative mechanism.
That's not a dependency, that's a conflict. Alternatives are not always
the answer to a conflict. Consider that there is no package that (even
natively) supplies /usr/bin/editor, yet we have an alternative for that.
Note that by default, neither nvi nor vim[1] builds a binary called
"vi".
> What we _can_ agree on is the value of having multiple MTAs on one
> box.
Just to be explicit here: I think the value is low, and that those who
do need/want such a set up usually have a specific sitation that would
not be suited by generic pre-packaged support for such.
> > OTOH, you don't need the same thing for Conflicts because conflicts
> > are bi-directional. So long as a given package Conflicts with all the
> > *existing* packages, you don't have to worry about future packages,
>
> This is probably required, but not met in practice for some of the
> DNS stuff, and this gave rise to the idea of having more virtual
> packages. You only need to overlook some other package out there
> when you put up your own, thus failing to list a conflict, and
> the user's machine may be in a weird state.
We already have a mechanism for dealing with such a situation: we
call it a "bug report".
> Having a virtual package makes this process more fail safe.
Not for the general case. Unless you want to create a virtual package
for every possible conflicting situation.
> This is right so far, but currently there is DNS server management
> software at least that demands certain DNS server software on the
> same host (for imho no good reason).
If it requires a particular DNS package, then how does having a virtual
package help? You'll note that eximon (Exim GUI/monitor) doesn't depend
on "mail-transport-agent".
> > And yes, I understand that there are counter examples in the archive now
> > (someone mentioned imap-server). They're wrong. There is no reasonable
> > way to depend on imap-server, and solving the conflicts doesn't need a
> > virtual package.
>
> Please say why the example is wrong. As far as I understood, the
> example is a real-world example, and thus "right".
There's no useful service provided by having an "imap-server" virtual
package. Nothing can Depend on it, because it's quite reasonable for it
to be on a different machine. And I've already said I don't think that
virtual packages are necessary or useful for Conflicts.
As a counter example, note that there is an httpd vitual package, and we
have several HTTP servers in Debian. None of them conflict with httpd -
is used solely for Depends/Recommends/Suggests with web apps. We have
multiple SQL servers, but no sql-server virtual package, because there's
no useful dependency you can declare on a *generic* network capable SQL
server.
Most of the existing virtual packages seem to be in support of different
versions of development libraries. There, the conflict makes sense -- if
you need to build against a different version, install it.
There's some absolutely useless virtual packages too: there's an "irc"
package, which seems to be provided by some (but not all) of the irc
*clients* in Debian, but as NOT ONE D/R/S/C declared against it.
Completely pointless. Of course, that's typical of *anything* related to
IRC :-).
Someone[2] should go through the list of and get rid of the cruft.
> Things on disk can most often be shuffled around, and symlinked to,
> but detecting and accomodating the usage of IP numbers and ports is
> imho hardest and usually most volatile, too.
I guess I don't agree with that, because if you have multiple
packages listening on the same port, either you configure them in a
non-conflicting way (different IP interfaces, for example) or one of
them binds to the port and the other(s) fail to start. There is room for
proper system management, after all. If you make all the DNS packages
conflict, just because they might use the same port, then you make it
hard for me to do something clever. And that's not, IMO, what Debian's
about.
So, in summary (finally!), I think you've noticed a legitimate problem
(inconsistant use of Conflicts among various DNS packages), but have
selected the incorrect mechanism to fix it. The easy way out is to
report bugs against the various DNS packages, and let the maintainers
work it out.
Steve
[1] I know that's true for nvi, not sure if it's still true for vim.
[2] Someone other than me.
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Reply to: