[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Unnecessary "Conflicts" with imap-server packages



On Thu, Aug 25, 2005 at 01:04:28PM +1000, Brian May wrote:
> >>>>> "Gerrit" == Gerrit Pape <pape@smarden.org> writes:
>     Gerrit> </usr/share/doc/bincimap-run/README.Debian The
>     Gerrit> bincimap-run package provides the virtual package
>     Gerrit> ``imap-server'' and conflicts with other packages
>     Gerrit> providing ``imap-server''.  This ensures that bincimap is
>     Gerrit> the only service that listens on the address 0.0.0.0:993
>     Gerrit> on a system, and also satisfies packages that depend on a
>     Gerrit> running imap service.  The bincimap package without the
>     Gerrit> bincimap-run package can be installed alongside other
>     Gerrit> imap-server packages on a system, e.g. to provide
>     Gerrit> different imap or imaps services on different addresses
>     Gerrit> simultaneously.
> 
> So are you suggesting that every imap-server (for example) should be
> split into two packages?
> 
> Taken a step further this would include every server where multiple
> implementations exist.

I suggest to split all packages providing service(s) into one package
containing the programs, documentation, examples, and one package
setting up the default service(s) to be run automatically.  See these
threads

 http://lists.debian.org/debian-devel/2004/04/msg00080.html
 http://lists.debian.org/debian-devel/2004/02/msg01390.html

I'm doing this for nearly all of the packages I maintain since years,
works just fine.

> Is this really a good idea?

Yes, why not?  It solves the OP's problem; it lets you install packages
that provide a service without enabling the service automatically; it
uses the dpkg dependency facility to show or solve conflicts; it adds
flexibility, and avoids unnecessary conflicts.

You might say it blows up the Packages file.  Well, yes, but I don't
think the scalability problem with the number of packages included in
Debian should stop us developing good design choices, or adding new good
quality packages to Debian.  I'm confident the problem will be solved
technically some day.

Regards, Gerrit.
-- 
Open projects at http://smarden.org/pape/.



Reply to: