Re: cleaning up courier-* packages

Guillaume Rousse <[email protected]> Mon, 22 May 2006 16:49:28 +0200
Newsgroups gmane.linux.mandrake.server
Message-ID <[email protected]>
Oden Eriksson wrote:
> s=F6ndagen den 14 maj 2006 17.39 skrev Guillaume Rousse:
>> I started a large cleanup of courier packages (courier-authlib, and
>> courier-imap). I already get rid of triggers, duplicated config files,
>> and replaced original initialisation system with a standard one.
>>
>> I'm curious however about the usefulness of conditional build options
>> and care about packages non included in the distribution, such as
>> vpopmail support in courier-authlib, and renaming of maildirmake in
>> courier-imap to avoid conflict with qmail. Are they really useful ?
>> Because otherwise, I'd rather drop them: simpler packages are easier t=
o
>> maintain.
>=20
> No, you can do what you want here. If you choose to upgrade courier-ima=
p to=20
> 4.x there is no more vpopmail support.
>=20
> Thanks for taking the time.
I'm currently investigating the dlopen issue with upstream developpers,
but I have other issues in mind.

The first one is package and file naming. Current one strictly reflect
upstream distribution:
- courier-authlib subpackages are named courier-authlib-foo
- courier-authlib subpackages have their configuration in
/etc/courier-autlib
- courier-imap subpackages are named courier-imap-foo
- courier-imap subpackages have their configuration in /etc/courier-imap

Another repartition would be to only keep a short courier-prefix to all
subpackages, whatever their exact upstream distribution:
- courier-authdaemon
- courier-imap
- courier-pop
- courier-authlib
And to have all configuration files under /etc/courier

I find the second one more logical from user point of view.

Second issue, the SSL stuff handling. Is there any specific instruction
how to handle certs configuration, cert files and cert files generation
now ?