Why does security/amavisd-new depend on db3?

[Michael C. Shultz]

On Tuesday 15 November 2005 09:44, Michael C. Shultz wrote:
> On Tuesday 15 November 2005 06:37, Craig Boston wrote:
> > On Mon, Nov 14, 2005 at 10:59:44PM -0800, Michael C. Shultz wrote:
> > > The WITH_BDB_VER=42 only needs to be applied to
> > > databases/p5-BerkeleyDB,
> >
> > In theory, yes, however for dependencies to be registered properly it is
> > needed for the top level port as well.
> >
> > Look at line 5012 of bsd.port.mk, where it populates the +CONTENTS file.
> > PKG_ARGS is defined on line 2052 and issues a "make package-depends"
> > command, which recursively gown down the ports tree building a list of
> > dependencies.  However, as previously demonstrated, that list is based on
> > the _current_ environment of the package that is being installed at that
> > moment.
> >
> > > when "portmanager security/amavisd-new" is run ports will build in this
> > > order:
> > >
> > > ports/databases/db42			before
> > > databases/p5-BerkeleyDB		before
> > > security/amavisd-new
> >
> > The behavior can easily be reproduced with manual builds by doing them
> > in that same order:
> >
> > cd /usr/ports/databases/p5-BerkeleyDB; make install WITH_BDB_VER=42
> > cd /usr/ports/security/amavisd-new; make install
> >
> > The second command will install amavisd-new with an erroneous pkgdep on
> > bdb3.
> >
> > Doing with second install with WITH_BDB_VER=42 set will cause it to be
> > correct.  The first install is unnecessary in this case, but portmanager
> > would install it separately like that.
> >
> > ISTM the only way to work around it would be for portmanager to keep
> > track of which ports were built with what flags, and add those same
> > flags to any port that depends on them...
> >
> > Craig
>
> Hmm, I just checked /var/db/pkg/amavisd-new-2.3.3,1/+CONTENTS
> and you are correct, there really is a  databases/db3 in there!
>
> @pkgdep db3-3.3.11_2,1
> @comment DEPORIGIN:databases/db3
>
> but if you do this:
>
> cd /usr/ports/security/amavisd-new
>
> make -V RUN_DEPENDS -V LIB_DEPENDS
> {No WITH_BDB_VER=42 switch}
>
> /usr/local/lib/perl5/site_perl/5.8.7/mach/Unix/Syslog.pm:/usr/ports/sysutil
>s/p5-Unix-Syslog
> /usr/local/lib/perl5/site_perl/5.8.7/MIME/Words.pm:/usr/ports/mail/p5-MIME-
>Tools
> /usr/local/lib/perl5/site_perl/5.8.7/Convert/TNEF.pm:/usr/ports/converters/
>p5-Convert-TNEF
> /usr/local/lib/perl5/site_perl/5.8.7/mach/Convert/UUlib.pm:/usr/ports/conve
>rters/p5-Convert-UUlib
> /usr/local/lib/perl5/site_perl/5.8.7/mach/Compress/Zlib.pm:/usr/ports/archi
>vers/p5-Compress-Zlib
> /usr/local/lib/perl5/site_perl/5.8.7/Archive/Tar.pm:/usr/ports/archivers/p5
>-Archive-Tar
> /usr/local/lib/perl5/site_perl/5.8.7/Archive/Zip.pm:/usr/ports/archivers/p5
>-Archive-Zip
> /usr/local/lib/perl5/site_perl/5.8.7/Net/Server.pm:/usr/ports/net/p5-Net-Se
>rver
> /usr/local/lib/perl5/site_perl/5.8.7/Mail/SpamAssassin.pm:/usr/ports/mail/p
>5-Mail-SpamAssassin
> /usr/local/lib/perl5/site_perl/5.8.7/mach/BerkeleyDB.pm:/usr/ports/database
>s/p5-BerkeleyDB /usr/local/bin/arc:/usr/ports/archivers/arc
> /usr/local/bin/unfreeze:/usr/ports/archivers/freeze
> /usr/local/bin/lha:/usr/ports/archivers/lha
> /usr/local/bin/lzop:/usr/ports/archivers/lzop
> /usr/local/bin/unarj:/usr/ports/archivers/unarj
> /usr/local/bin/unrar:/usr/ports/archivers/unrar
> /usr/local/bin/zoo:/usr/ports/archivers/zoo
> /usr/local/bin/cabextract:/usr/ports/archivers/cabextract
> /usr/local/bin/rpm2cpio.pl:/usr/ports/archivers/rpm2cpio
> /usr/local/lib/perl5/site_perl/5.8.7/mach/Mysql.pm:/usr/ports/databases/p5-
>DBD-mysql
> /usr/local/lib/perl5/site_perl/5.8.7/mach/DBD/Pg.pm:/usr/ports/databases/p5
>-DBD-Pg
> /usr/local/lib/perl5/site_perl/5.8.7/Net/LDAP.pm:/usr/ports/net/p5-perl-lda
>p /usr/local/bin/perl5.8.7:/usr/ports/lang/perl5.8
>
> The db dependencies stop at
>
> /usr/local/lib/perl5/site_perl/5.8.7/mach/BerkeleyDB.pm:/usr/ports/database
>s/p5-BerkeleyDB
>
> which is correct according to
>
> /usr/ports/security/amavisd-new/Makefile who for db only lists:
>
> ${SITE_PERL}/${PERL_ARCH}/BerkeleyDB.pm:${PORTSDIR}/databases/p5-BerkeleyDB
>
> Anyways, the extra, unnessesary and INCORRECT entries in +CONTENTS would
> indeed have caused portmanager problems a short while ago.  Portmanager
> used to only use the +CONTENTS file to determine dependencies and in this
> case that would definitely cause trouble.
>
> Beginning with ver 0.3.1 Portmanager started also collecting dependencies
> using make -V *_DEPENDS and so now has two dependency databases:
>
> ports_dependencies.db which come from +CONTENTS
> and ports_available_dependencies.db
> which come from make -V *_DEPENDS
>
> The idea is that ports_available_dependencies.db overrides
> ports_dependencies.db, but this has been tricky in practice.
>
> I released version 0.3.5 a little earlier than intended because in an
> unrelated report there was a case where portmanager got the priority wrong
> between these two data bases and that was fixed in 0.3.5.
>
> You pointed out very clearly that my understanding of +CONTENTS was flawed,
> because I allways believed it recorded the dependencies used to build after
> the fact, which it clearly doesn't.
>
> Bottom line is portmanager 0.3.5 should be able to build
> security/amavisd-new as intended and by my own tests it does.  My
> understanding of the
> bsd.ports.mk language is poor, but 5027 - 5034 look suspicious.
>
> Probably no one cares but I can't think of a single good reason to
> transvers dependent port's dependencies when adding dependencies to
> +CONTENTS. The fact they do should no longer cause portmanager troubles but
> if Jiawei is to be believed it looks like portupgrade might be being
> negatively effected by these unnessesary and incorrect entries..
>
> -Mike

Damn, I just found one portmanager routine that only works the old way:

portmanager -s (only reports installed ports status) and it hosed because of
this.  The upgrade routines are OK though.  Well off to squash yet another
one <sigh>.....

-Mike