tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: multi-variant packages and bulk builds
On Sat, 06 Sep 2008, Aleksey Cheusov wrote:
> > In pkgsrc there are a number of packages (category/package) that can
> > be built with different PKGNAME depending on a value of some special
> > variables. For example, www/ap2-* packages, */py-* and many others.
>
> Based on suggestion (VARIANTS variable) described above, I've update
> pkg_src_summary program. Now it can generate summary for all variants
> of multi-variant packages and even more. See below ====.
I haven't really been following this discussion, btu I have a related
problem involving "make replace" with such packages. It's easiest to
explain using an example.
Say I have installed python-2.4 and python-2.5.
Then I install some addon module for both of them:
cd pkgsrc/devel/py-pexpect
make clean ; make PYTHON_VERSION_DEFAULT=24 install
make clean ; make PYTHON_VERSION_DEFAULT=25 install
Some time later, possibly after some cvs updates, I ask
pkg_rolling-replace to rebuild them both:
sudo pkg_admin set rebuild=YES py\*-pexpect-\*
cd pkgsrc
pkg_rolling-replace
Internally, pkg_rolling-replace does something like this:
# try to replace py24-pexpect-*
cd pkgsrc/devel/pexpect
make clean ; make replace ; make clean
# try to replace py25-pexpect-*
cd pkgsrc/devel/pexpect
make clean ; make replace ; make clean
but it's not passing PYTHON_VERSION_DEFAULT into the build, so instead
of rebuilding both packages, it ends up rebuilding one of the packages
twice, and displaying several error messages.
To fix this, I think the package itself should somehow encode the
fact that, when trying to "replace" it, you need to pass the correct
value for PYTHON_VERSION_DEFAULT. If a future version of the pkgsrc
infrastructure stored "VARIANTS=PYTHON_VERSION_DEFAULT=24" in the
+BUILD_INFO file, then a future version of pkg_rolling-replace could do
the right thing.
--apb (Alan Barrett)
Home |
Main Index |
Thread Index |
Old Index