Re: suggested virtual package name: dns-server
Hi Steve,
On Fri, Jan 10, 2003 at 10:27:14AM -0600, Steve Greenland wrote:
> (Sigh, this goes on much longer than I had originally intended. Feel
> free to skip to the last few paragraphs.)
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.
> On 09-Jan-03, 15:55 (CST), Toni Mueller <toni@debian.org> wrote:
> > 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:
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.
[ perusing your vim/nvi example]
The question "What constitutes a conflict?" was _not_ aimed at the
technical reason of being unable to have eg. a /usr/bin/vi file
in different packages. 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 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. 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.
> 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. All
halfway-decent software, and at least all that comes with source,
can be bent in a way to avoid such namespace clashes. So in theory,
if you don't like to declare a conflict, choose some prefix, suffix,
maybe different installation paths, to resolve it before installation.
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.
> 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. Ie, the conflicting situations
you described are on the file level, too, and nothing would conflict
if eg. both nvi and vim would provide only /usr/bin/nvi and
/usr/bin/libnvi.so, and /usr/bin/vim and /usr/lib/libvim.so (just
a contrived example to illustrate), so the conflict can in these
cases also be solved at the file system level using alternatives.
> 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
Yes.
> All the MTAs conflict because not only do they provide
> /usr/sbin/sendmail (which would be easy enough to make alternative, but
I thought so. The packages I've seen so far usually make
/usr/sbin/sendmail a symlink to a different file anyway.
> 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).
Sorry, but for the case of MTAs I disagree. Yes, policy demands that
the mailboxes are stored under /var/spool/mail (which I happen to
disagree with, too), but I wouldn't vouch for the requirement of
/etc/alias and the like.
What we _can_ agree on is the value of having multiple MTAs on one
box. What we can agree on less is the need of having multiple
packages out of the DNS area installed simultanously.
> 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.
Yes (known already)...
> 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. Having a virtual
package makes this process more fail safe.
> 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.
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).
> 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?
No. The problem I intend to solve is that apparently the DNS server
software, covering various aspects of functionality, imho does not
declare proper conflicts, and that I thought that having a virtual
package name would make the cleanup process easier. Plus, I'm
under the impression that there is more DNS server software to
be packaged for Debian that has the potential of making the mess
greater.
> 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".
I also didn't say that there is no other way to solve a conflict,
but I still think that having virtual packages can reduce the
complexity of doing so.
> 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
Yes...
> different directory trees for their libraries, and pretty hard for
> things that share on disk infrastructure.
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.
Best,
--Toni++
Reply to: