Re: suggested virtual package name: dns-server
(Sigh, this goes on much longer than I had originally intended. Feel
free to skip to the last few paragraphs.)
On 09-Jan-03, 15:55 (CST), Toni Mueller <toni@debian.org> wrote:
>
> 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.
I think you need to go read the policy manual and various other
Debian packaging information again, because you (and Scott, in
the other reply to my message), have completely missed what
Depends/Recommends/Suggests/Conflicts, alternatives, and virtual
packages are about, and how they interact. (Okay, to be fair, it's not
really well explained; one really needs to read the archives to see why
each piece was invented, and what problem was being solved.) Let me try
to summarize:
A Dependency exists when one package relies on the existence of another
to perform it's function. This may be a simple library dependency, or
it may be because it uses a binary provided by the dependended upon
package. A very obvious example is an MUA that runs /usr/sbin/sendmail
to send an e-mail message. This is not a matter of taste. Recommends
and Suggests are "softer" ways of describing similar relationships, and
exist primarily as hints to the package selection tools (dselect at the
time; now aptitude, gnome-apt, etc.)
A Conflict exists when two packages cannot be installed on the system
at the same time. The primary reason for this is that both include the
same file. The straight-forward case might be /usr/bin/vi from both nvi
and vim, or /usr/bin/awk from both gawk and mawk. A less obvious example
is splitting a package, requiring a versioned conflict with the older
version of the parent package. Other reasonable conflicts are (well,
used to be) encryption enabled and non-encyption enabled versions of a
package.
Of course, some conflicts are unreasonable: it's quite common to want
both vim and nvi on the same machine. Some users like one, some the
other. Alternatively, some scripts might require gawk, some mawk,
and some work fine with either one, and you can't force the admin
to de-install gawk and install mawk just to run a script. Thus, the
alternative system was created. Note that this is on a *file* level, and
has nothing to do with dependencies.
Virtual packages arose to allow a package to declare a dependency on an
*interface* rather than a specific implementation of that interface. For
example, /usr/bin/sendmail (plus a subset of options) is an interface
to the MTA. When the only MTAs in Debian were sendmail and exim, it
was feasible for an MUA to depend on the specific packages. As the
number of MTAs grew, that became impossible (or, at least, extremely
inconvenient), and thus the idea of the virtual package.
> 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.
All the MTAs conflict because not only do they provide
/usr/sbin/sendmail (which would be easy enough to make alternative, but
also because they share a significant bit of infrastructure (/etc/alias,
/var/spool/mail) which would be damn hard to deal with in any sort of
automated fashion, *and* because the value of doing so (i.e. not very
many people have any use for multiple simultaneous MTAs).
But more generally, note what virtual packages are for: so that other
packages can declare a general *dependency* on the virtual package,
knowing that any of the packages Providing that virtual package will
supply that interface. In particular, it allows a package to depend on a
package that didn't even *exist* when the depending package was created.
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,
because *they will conflict with you*. Dependencies are directional, but
Conflicts are not. Sendmail doesn't need to Conflict with any other MTA,
so long as the other MTAs Conflict with it.
So, if you're still reading after all that long-winded pontification,
what problem does creating a dns-server virtual package solve? No
DNS server provides an interface for other packages: they call
gethostbyname(3), which is provided by libc. Or they call of the
resolver(3) functions, also provided by libc. It makes no sense to
depend on dns-server, because it's perfectly reasonable to have your DNS
server on another machine.
So that leaves Conflicts, and you don't need virtual packages to solve
that problem, just a standard practice of declaring proper Conflicts, as
they exist at the time you upload your package. You might have a minor
problem if two maintainers upload the two new implementations of the
same server at (roughly) the same time, but realistically, that's not
likely, is it?
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.
Now, as to whether a given set of servers should Conflict or use
alternatives, I think that's up to the maintainers involved. It's
easy and useful for things like nvi/vim, and not too hard for (e.g.)
different versions python, which can use a couple of alternatives and
different directory trees for their libraries, and pretty hard for
things that share on disk infrastructure. The good news is that the hard
cases are also usually the ones of least interest (e.g. MTAs), except
for the few people making transitions. I don't think we can or should
hard-code the choice into policy, as it's a value judgement between the
difficulty and the usefulness.
Steve
--
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: