Re: Unnecessary "Conflicts" with imap-server packages
- To: debian-devel@lists.debian.org
- Subject: Re: Unnecessary "Conflicts" with imap-server packages
- From: Gerrit Pape <pape@smarden.org>
- Date: Fri, 4 Nov 2005 10:34:06 +0000
- Message-id: <[🔎] 20051104102846.15548.qmail@5ae86cc05a6e55.315fe32.mid.smarden.org>
- Mail-followup-to: debian-devel@lists.debian.org
- In-reply-to: <20050829134147.GA4092@cloud.net.au>
- References: <20050823113215.GA21776@tropic.org.uk> <20050823121008.16728.qmail@e7366648c41409.315fe32.mid.smarden.org> <sa4mzn61zur.fsf@snoopy.microcomaustralia.com.au> <20050829075102.22710.qmail@6833026f230110.315fe32.mid.smarden.org> <20050829090634.GA873@cloud.net.au> <20050829102449.5758.qmail@7b8463b7da0d73.315fe32.mid.smarden.org> <20050829134147.GA4092@cloud.net.au>
On Mon, Aug 29, 2005 at 11:41:47PM +1000, Hamish Moffatt wrote:
> On Mon, Aug 29, 2005 at 10:29:20AM +0000, Gerrit Pape wrote:
> > files. I haven't heard any reason yet why splitting the packages would
> > be a bad thing.
> >
> > And there's more advantages: it eases usage of different service
> > managers than sysvinit and init scripts, support of a different init
> > scheme can be done through an alternative package which 'provides' the
> > default *-run package; same for services running under a superserver,
> > and corresponding alternatives; it plays well with fully automated
> > installs; it separates services from programs.
>
> These problems should be solved by discussion and generation of a
> policy. IMHO it would be better to have a consistent approach that
> didn't solve every problem (or had some other flaw) than to have
> each individual developer generate their own scheme.
Well, as far as my experience goes, simply discussing things doesn't
work out. It stops at some time, and almost never reaches a real
solution. Better introduce a technical solution that actually works,
and then come up for discussion. If you re-read this thread, you see
the different opinions on how services and conflicts should be used, and
how my recommendation, already implemented in packages I maintain,
solves all this.
I still haven't heard any reason yet why splitting the packages would
be a bad thing, and tried to show the lots of advantages.
Regards, Gerrit.
Reply to: