splitting courier-authlib into master+slave ports

[Jose M Rodriguez]

El Wednesday 20 April 2005 20:27, Yarema escribió:
> --On Wednesday, April 20, 2005 12:12:54 +0200 Oliver Lehmann
>
> <lehmann at ans-netz.de> wrote:
> > Milan Obuch wrote:
> >> On Tuesday 19 April 2005 17:30, Oliver Lehmann wrote:
> >> > Jose M Rodriguez wrote:
> >> > > Hope this may be on time.  Can you consider work this?
> >> > >
> >> > > - maintain couier-auhlib just as a metaport selector.
> >> > > - add a courier-authlib-base port
> >> > > - maintain the courier-authlib-method ports, but working
> >> > > against courier-authlib-base.
> >> >
> >> > That sounds cool. then OPTIONs could be put into the metaport.
> >> > I'll work on this.
> >>
> >> I like this idea too. Actually I was trying to formulate tha same.
> >> You were  quicker :)
> >> Milan
> >
> > Can you try the tar.gz once more? I uploaded an "adjusted" version
> > ;)
>
> FWIW I'd like to weigh in with my opinion.  I think this move to a
> meta port just so we can have OPTIONS selectable dependencies does
> little to improve usability.  As I've argued before in an email to
> Oliver there's little need to have more than one
> courier-authlib-method port installed unless one is transitioning
> from one auth-method to another or just experimenting.
>

Maybe,  but you can trust me in this:  have the base port and the 
components selector in the same place it a bad design.


> So why is it better to:
> % cd courier-authlib && make config && make install
> rather than just:
> % cd courier-authlib-METHOD && make install
>

This is only about maintain courier-athlib 'working as before', and make 
portupgrade cope with the transition.

> (Yes, I know the 'make config' is not necessary ;) my point still
> stands.)
>
> We're just adding unnecessary complexity just because we can.  A
> pkg-message in the base port (without OPTIONS) is sufficient to
> indicate to the user that other method ports are available IMHO.
>
> The "adjusted" versions of courier-authlib as I presented it to
> Oliver can be found at  <http://yds.CoolRat.org/freebsd/>
>
> The most recent one one incorporates some of the adjustments Oliver
> made to his version.
>
> One difference between the courier-authlib-20050408.00.tgz version
> and courier-authlib-20050420.00.tgz is that I make --with-authpam
> part of the base port's CONFIGURE_ARGS. This prevents libauthpwd.so.0
> from being built and instead builds
> lib/courier-authlib/libauthpam.so.0.  authpwd is discouraged as per
> <http://www.courier-mta.org/authlib/README_authlib.html>:
>
> NOTE:  It might be tempting to throw in a towel and use authshadow or
> authpwd if you cannot figure out how to install PAM support, however
> that is not advisable. It is highly recommended to use authpam
> wherever the PAM library is available.
>

We have a FreeBSD supported version without a pam library?  I think no.

> The authpwd module is also documented in the same README to use "the
> C library's getpw() functions" which in turn are documented to be
> made "made obsolete by getpwuid(3)" in the FreeBSD getpw(3) man page.
>
> So given the above two citations from both courier-authlib docs and
> FreeBSD's docs why not just do away with authpam being optional and
> make it the default part of the base package?
>

The rest is out of the scope of my little observation.

<snip/>

--
  josemi