splitting courier-authlib into master+slave ports

Jose M Rodriguez josemi at freebsd.jazztel.es
Mon Apr 25 00:06:34 PDT 2005

El Lunes, 25 de Abril de 2005 06:19, Yarema escribió:
> --On Sunday, April 24, 2005 18:55:28 +0200 Oliver Lehmann
> <lehmann at ans-netz.de> wrote:
> > Oliver Lehmann wrote:
> >> Ok, you both convinced me. I'll change -base (allready done, I'm
> >> testing)
> >
> > It's uploaded now. I also changed sysconftool to a build-dep since
> > we need ed during the install target and not later, and we don't
> > need it after the installation for a running courier-authlib.
> Oliver, as usual a couple of notes regarding the latest you uploaded
> :)
> .if ${AUTHMOD} == authbase
> CONFIGURE_ARGS+=--with-base --with-pam
> shouldn't that be:
> CONFIGURE_ARGS+=--with-base --with-authpam
> Also you reintroduced:
> .endif
> This is handled at runtime by the:
> files/patch-authdaemond.in
> files/patch-authdaemonrc.in
> patches.  Of course it does no harm, but there's no need to tweak the
> compile time --with-syslog= if one is free to tweak it at run time
> all they want.

This is a compat env to previous versions of courier-authlib and 
courier-imap.  I can't found a reason to break existing functionality.
> The pkg-descr-pwd still refers to /etc/pwd.db instead of getpw() or
> getpw(3).  Of course the authpwd subport could be sent to the great
> bit-bucket in the sky and nobody would miss it.. ;) but I don't
> really care anymore.  Thanks for making PAM the default. :)
> One last note.  There's a few places where portlint complained that
> you have blank spaces at the end of the line:
> Lines 45 and 62 in your version of Makefile.ext
> /\s\+$// will fix them in vim.
> And a few places where you have spaces instead of tabs indenting the
> line: Lines 58,60,61,63,64,66,67,68,69 and 78 in Makefile.ext
> /  \+/ will find these.
> Most likely artifacts of cutting and pasting.
> One of the advantages of not having Makefile.ext as a separate file
> is that portlint helps find such things.  I ran portlint and fixed
> these every time I posted a tweaked version of the port for you to
> review.

I also become to think that if we only import Makefile.ext from Makefile 
and we import Makefile from slave ports, there isn't no real reason to 
not merge Makefile.ext code directly into Makefile.

> And one last idea I had was that if you were to adopt the standalone
> meta and stand alone base organization I demonstrated.  Then the

This have a mayor drawbacks: you must hand sync things like PORTVERSION 
into both.  And include a common Makefile.inc has never the placet of 

> naming could go back to courier-authlib without -base and a
> courier-authlib-meta.  And if we were to go that way then why not a

This will break any prob that portupgrade may chase the split.  The port 
will 'All' the functionality, including actual options, will be 

I even doubt if it is a good idea moving this from mail to security.  
Adding a security category will be simple. And not need a repocopy 
request. Just add the components ports and make an update.

> courier-meta where we could select not only courier-authlib

No.  You can't make all the functionality of courier from actual 
component.  Also, there are people like me that don't like courier as a 

> BUILD_DEPENDS but whether to install courier or courier-imap and/or
> sqwebmail. With Makefile.opt and Makefile.dep available why do we
> need a meta port and a -base? This strays from the naming convention
> used by rpm based packaging.  Just a thought...

be carefull with this aproach.  We can't make 'subproducts' from a build 
like rpm.

In the ports system, this will end up with more real work to do and 

Keep this simple when possible, it's very common found that you doesn't 
have the resources to maintaint your 'criatures' when live goes on.


More information about the freebsd-ports mailing list