Date: Wed, 16 Nov 2005 08:43:47 -0800 From: "Michael C. Shultz" <ringworm01@gmail.com> To: Scot Hetzel <swhetzel@gmail.com> Cc: Craig Boston <craig@yekse.gank.org>, Jiawei Ye <leafy7382@gmail.com>, freebsd-ports@freebsd.org Subject: Re: Why does security/amavisd-new depend on db3? Message-ID: <200511160843.48602.ringworm01@gmail.com> In-Reply-To: <790a9fff0511160827g183c5267v4980deaf22eded02@mail.gmail.com> References: <c21e92e20511130557g4ad76176l85beb6ceee078886@mail.gmail.com> <20051115212859.GA71557@nowhere> <790a9fff0511160827g183c5267v4980deaf22eded02@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 16 November 2005 08:27, Scot Hetzel wrote:
> On 11/15/05, Craig Boston <craig@yekse.gank.org> 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
>
> Thanks for taking the time to explain the problem further, I was
> trying to, but had only a few minutes to formulate my answer.
>
> Scot
Scot, I'd like to thank you for the effort you made trying to get me to
understand. It paid off big time, now that I finally understand the problem
I was able to devise a cure that will let people use WITH_* options on the
command line again, and help portupgrade users get less errors as well.
I added a routine to portmanager that generates a correct packing list when
a port is installed or when someone creates a package, that and a small patch
to bsd.ports.mk and the problem is solved. I've been testing the fix since
last night on a 5.4 and 6.0 system, so far results are promising, shortly
I'll be submitting a PR with a proposal to fix this, hopefully someone on the
ports team will take an interest.
-Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511160843.48602.ringworm01>