tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Various size of (Project) ideas for NetBSD and pkgsrc
On Wed, Oct 02, 2013 at 02:42:06AM +0200, Alistair Crooks wrote:
> > [multiple output packages from one build]
>
> Non-trivial work, for little (I'm being nice, I can't see any
> whatsoever) gain. No-one has yet been able to tell me what the gains
> are to this approach, only that the approach is possible.
The gains are:
- you only have to do one build
- we don't have to do major surgery to poorly-architected packages
- less clutter
ISTM that from a certain point of view the ideal is a single pkgsrc
source directory, that produces a base binary package and one
additional plugin package for every option you have enabled; then if
you're building you can build exactly what you want, and if you're
using binary packges you can install exactly what you want.
One can get to a similar place by having separate pkgsrc directories
for each of the plugin packages; that is not as tidy though, and it
doesn't always interact well with the upstream package's configure and
build.
The chief problem I see is that it's going to produce bad interactions
with multiversion support; e.g. if building subversion produces both
subversion-base and py-subversion packages, then you still have to
build it N times for N different Python versions but now you either
get N different subversion-base packages (which is crazy) or some kind
of mess to avoid this (which is worse than the default state).
It's possible that there exist packages that can build their Python
plugins for all available Python versions at once in a single pass,
but I don't think I've ever seen one and our infrastructure can't
currently support it.
Because of this I'm not sure how multiple output packages support is
supposed to help with postfix and mysql...
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index