Hi,

I'm trying to use the result of a pkgsrc bulk build to upgrade
one of our machines.  To this end I've been using my own proof-
of-concept script, which archives old packages, transfers new
packages, complains if the new set has internal conflicts, and
leaves behind a pair of scripts, one for removing the out-of-date
packages in the right order, and one to add the new packages.

However, this is revealing a couple of problems...

The machine in question runs packages from 2006Q1, and I'm trying
to upgrade to the result of a 2006Q3 build.  The machine runs
Apache 1, and in this round I was thinking I should retain Apache
1.  The machine has the p5-HTML-Mason package installed.  The
thing is, p5-HTML-Mason can probably be built for both Apache 1
and Apache 2 from source, but with no special tweaks from my side
for selecting which version to prefer in the bulk build, it now
appears that the .mk setup in mk/apache.mk and related files has
changed the default choice which now ends up conflicting with my
desire to retain Apache 1 and to be able to upgrade only using
the binary packages resulting from the bulk build.

The reason is that the binary package p5-HTML-Mason-1.31.1nb2
depends on ap2-perl-2.0.1nb3, probably via a default choice of
"Apache 2" by the .mk files.  Thus, I'm unable to install
p5-HTML-Mason from the binary package set.

A couple of questions:

1) Do we aim at solving this problem, or is "build that package
   from source, then" an acceptable answer?  (It would be nice if
   we supported use of binary packages...)

2) What does other packaging systems which encounter similar
   issues do?  Build the same package multiple times with
   different package names depending on the options chosen?  Will
   adhering to this cause an explosion in the number of packages
   we need to build?

Comments?

Regards,

- H=E5vard