splitting courier-authlib into master+slave ports
yds at CoolRat.org
Thu Apr 21 02:02:39 PDT 2005
--On Thursday, April 21, 2005 8:57 AM +0200 Jose M Rodriguez
<josemi at freebsd.jazztel.es> wrote:
> El Jueves, 21 de Abril de 2005 01:48, Yarema escribió:
>> --On Wednesday, April 20, 2005 21:44:11 +0200 Jose M Rodriguez
>> <josemi at freebsd.jazztel.es> wrote:
>> > El Wednesday 20 April 2005 20:27, Yarema escribió:
>> >> 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.
>> > 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?
>> Yes, we do have "a FreeBSD supported version without a pam library"
>> installed if only the base port is installed. I made this happen to
>> for the sake of completness and now I'm presenting arguments that it
>> is a bad idea. Thing is that the courier-authlib port, as it is
>> committed NOW, will install the no PAM version "libauthpwd.so.0" if
>> NONE of the OPTIONS are selected. Yet the PLIST in the current
>> version does not include "libauthpwd.so.0".
> No. It isn't the base port, it's the base system. I think that
> courier-authlib-base _must_ have pw/pam auth without options. Only
> select what type by libpam presence or OS_VERSION.
I think we're in agreement here. Because there is no OS_VERSION officially
supported by the ports system which does not have PAM in the base system.
FreeBSD 2.2.x == no PAM in the base system and has not been officially
supported by the ports tree since 4.x went STABLE.
FreeBSD 3.x == does have PAM in the base system, but as far as I know port
authors are not required to maintain comparability with 3.x either.
FreeBSD 4.x and 5.x and 6-CURRENT all have PAM in the base system.
So there's no need to check OS_VERSION since all versions of FreeBSD >= 3.x
have PAM in the base system. And the ports tree is only required to
support 4.x or greater, so it's safe to assume that PAM always exists in
the base OS_VERSION.
> Remember, this is about split in binary-compatible ports + metaport. No
> options or knobs may live in courier-authlib-base or
> Only the courier-authlib metaport will have this.
> I can't work on this until weekend, but I'll try to have a candidate on
Before you do take a look at
More information about the freebsd-ports