Why does security/amavisd-new depend on db3?

[Michael C. Shultz]

On Tuesday 15 November 2005 13:00, Scot Hetzel wrote:
> On 11/15/05, Michael C. Shultz <ringworm01 at gmail.com> wrote:
> > On Tuesday 15 November 2005 11:45, Scot Hetzel wrote:
> > > On 11/15/05, Jiawei Ye <leafy7382 at gmail.com> wrote:
> > > > On 11/15/05, Michael C. Shultz <ringworm01 at gmail.com> wrote:
> > > > > The WITH_BDB_VER=42 only needs to be applied to
> > > > > databases/p5-BerkeleyDB,
> > > > >
> > > > > when "portmanager security/amavisd-new" is run ports will build in
> > > > > this order:
> > > > >
> > > > > ports/databases/db42                    before
> > > > > databases/p5-BerkeleyDB         before
> > > > > security/amavisd-new
> > > > >
> > > > > I'm sure there is a simple explanaition for the problem if Jiawei
> > > > > would only post something demonstrating how things are going wrong
> > > > > for him instead of merely describing what he thinks is happening.
> > > > >
> > > > > -Mike
> > > >
> > > > I am trying to, Mike. Now that xorg-clients has a RUN_DEPENDS on
> > > > xterm, which lists xorg-clients as CONFLICT adds a lot to the
> > > > frustration :(
> > >
> > > The problem is rather complex, as there are two problems:
> > >
> > > 1. When using portupgrade, or portmanager they don't check if a
> > > depending port require having a variable set that is defined in these
> > > tools configuration files before upgrading an existing port.
> >
> >        Absolutly wrong, definitely for portmanager and likely for
> >        portupgrade.  The real problem is identified further down in this
> >        thread.
>
> What I was refering to is say you have a Port A, that depends on Port
> B.  Now Port B can depend on either Port C or Port D depending on if a
> WITH_X_VER variable is set.
>
> Now when you do  portupgrade/portmanager for Port A, the WITH_X_VER
> variable is not set in the tools config file for Port A, but is set
> for Port B.  This is what causes the wrong dependancy to be listed in
> the +CONTENT file for Port A.
>
> > > The work arround for this is to add the variable to /etc/make.conf:
> > >
> > > .if ${.CURDIR} == /usr/ports/databases/p5-BerkleyDB
> > > WITH_BDB_VER?=42
> > > .endif
> >
> >        Not nessesary. here is a sample portmanager output
> >        with the following in pm-020.conf
> >
> >        databases/p5-BerkeleyDB|WITH_BDB_VER=42|
> >
> >        Notice specifically:
> >
> > make fetch WITH_BDB_VER=42
> > make WITH_BDB_VER=42
> >
> >        If make fetch/clean/install etc is run portmanager does
> >        apply WITH_BDB_VER=42, test for yourself before saying
> >        such things, please.
>
> What I was refering to was the port that depended on this port was
> listing it's dependancies wrong in the + CONTENTS file. The use of the
> /etc/make.conf entry was a way to get arround this limitation in the
> bsd.port.mk's calculation of the dependancies for the port.
>
> Scot
>
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|

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)