Date: Mon, 25 Apr 2005 09:05:48 +0200 From: Jose M Rodriguez <josemi@freebsd.jazztel.es> To: freebsd-ports@freebsd.org Cc: Yarema <yds@CoolRat.org> Subject: Re: splitting courier-authlib into master+slave ports Message-ID: <200504250905.49493.josemi@redesjm.local> In-Reply-To: <D92E7F65549C970A625EA303@tuber.coolrat.org> References: <20050414111426.775f6afd.lehmann@ans-netz.de> <20050424185528.1799cd84.lehmann@ans-netz.de> <D92E7F65549C970A625EA303@tuber.coolrat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
El Lunes, 25 de Abril de 2005 06:19, Yarema escribi=F3:
> --On Sunday, April 24, 2005 18:55:28 +0200 Oliver Lehmann
>
> <lehmann@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} =3D=3D authbase
> CONFIGURE_ARGS+=3D--with-base --with-pam
>
> shouldn't that be:
>
> CONFIGURE_ARGS+=3D--with-base --with-authpam
>
> Also you reintroduced:
> .if defined(WITH_SYSLOG_FACILITY)
> CONFIGURE_ARGS+=3D--with-syslog=3D${WITH_SYSLOG_FACILITY}
> .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=3D 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=20
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=20
and we import Makefile from slave ports, there isn't no real reason to=20
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=20
into both. And include a common Makefile.inc has never the placet of=20
portlint.
> 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=20
will 'All' the functionality, including actual options, will be=20
courier-authlib.
I even doubt if it is a good idea moving this from mail to security. =20
Adding a security category will be simple. And not need a repocopy=20
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=20
component. Also, there are people like me that don't like courier as a=20
MTA.
> 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=20
like rpm.
In the ports system, this will end up with more real work to do and=20
maintaint.
Keep this simple when possible, it's very common found that you doesn't=20
have the resources to maintaint your 'criatures' when live goes on.
=2D-
josemi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504250905.49493.josemi>