Date: Tue, 15 Nov 2005 13:42:13 -0800 From: "Michael C. Shultz" <ringworm01@gmail.com> To: Craig Boston <craig@yekse.gank.org> Cc: Scot Hetzel <swhetzel@gmail.com>, Jiawei Ye <leafy7382@gmail.com>, freebsd-ports@freebsd.org Subject: Re: Why does security/amavisd-new depend on db3? Message-ID: <200511151342.15206.ringworm01@gmail.com> In-Reply-To: <20051115212859.GA71557@nowhere> References: <c21e92e20511130557g4ad76176l85beb6ceee078886@mail.gmail.com> <200511151301.16549.ringworm01@gmail.com> <20051115212859.GA71557@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 15 November 2005 13:29, Craig Boston wrote:
> On Tue, Nov 15, 2005 at 01:01:15PM -0800, Michael C. Shultz wrote:
> > This would still be wrong:
> >
> > .if ${.CURDIR} == /usr/ports/databases/p5-BerkleyDB
> > WITH_BDB_VER?=42
> > .endi
> >
> > It is equivalent to:
> >
> > in pkgtools.conf:
> > MAKE_ARGS = {
> > 'databases/p5-BerkeleyDB' => 'WITH_BDB_VER=42',
> >
> > in pm-020.conf
> > databases/p5-BerkeleyDB|WITH_BDB_VER=42|
>
> Actually, those are not quite equivalent. The make.conf entry should
> work around the problem. See below for details.
>
> > Maybe you mean to set it as a global
> > value ie. without the .if ${.CURDIR} == /usr/ports/databases/p5-BerkleyDB
> > wrapper? If that were the case it would still have no effect on
> > security/amavisd-new where the incorrect dependency is being recorded,
> > see for yourself:
> >
> >
> > cd /usr/ports/security/amavisd-new
> > /usr/ports/security/amavisd-new>grep WITH Makefile
> >
> > .if !defined(WITH_MILTER) || (!exists(/usr/lib/libmilter.a)
> > && !exists(${PREFIX}/lib/libmilter.a))
> > .if defined(WITH_MILTER) && !defined(AMAVIS_NOAMAVIS)
> > .if defined(WITH_MYSQL)
> > .if defined(WITH_PGSQL)
> > .if defined(WITH_LDAP)
>
> It would work either as a global or with the CURDIR trick, due to the
> way that the dependencies are being generated. It's true that the
> amavisd-new Makefile itself is unaffected by WITH_BDB_VER, but the
> p5-BerkeleyDB Makefile _IS_ evaluated at some point during the install of
> amavisd-new (regardless of whether it was already installed during that
> step or not).
>
> During the install phase of amavisd-new, the +CONTENTS file is generated
> in part from the output of "make package-depends-list"
>
> What package-depends-list does, is that for each of the LIB_DEPENDS and
> RUN_DEPENDS, it will do the equivalent of this pseudo-code:
>
> cd ${DEPEND_PORT_DIR} && make package-depends-list
>
> And will then print out each of its own LIB_DEPENDS and RUN_DEPENDS at
> the end. The effect is that each dependent port gets visited and
> evaluated, all the way up the chain (so dependencies of dependencies get
> visited, etc.), and a list of all deps is produced.
>
> Since this all happens at install time, if portmanager or portupgrade
> did not set WITH_BDB_VER in the environment before trying to install
> *amavisd*, the dependencies will be wrong. The MAKE_ARGS and such don't
> take effect because those tools don't know that those port directories
> are being visited (it all happens during a single "make install").
>
> make.conf, however, does get evaluated at every step of the way. So
> when the recursive makes are processed, and the dependencies for
> p5-BerkeleyDB are being queried, that variable will kick in (since
> CURDIR contains databases/p5-BerkeleyDB at that point).
>
> Craig
God this is getting ugly. If what your saying is true, and I have no doubt
that it is, then manuially installing port
databases/p5-Berkeley
by doing this:
make install clean WITH_BDB_VER=42 is goint to stil cause
security/amavisd-new to get its +CONTENTS file wrong
if it is installed later. This is not good behavior your describing.
Maybe the ports people are trying to force everyone to use OPTIONS
and render WITH switches on the command line as no longer feasable?
BTW your knowledge of the ports infrastructure is impressive, are you on the
ports team by any chance?
-Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511151342.15206.ringworm01>