Re: bulk-*

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Tue, Jan 22, 2013 at 06:53:38PM +0100, Alistair Crooks wrote:
 > Actually, there are the SPECIFIC_PKGS lists that can be placed in
 > mk.conf or equivalent, and then just issue a "make" from the top-level
 > pkgsrc directory, but that's not as good a way, I believe, as having a
 > separate meta-package.

Those invoke and/or are part of the old bulk build logic, aren't they?

 > > If you want to float an entire new scheme of lists of packges just so
 > > the bulk-* lists don't themselves have to be packages, be my guest,
 > > but it seems like a lot of work in pursuit of a minor abstract point.
 > > 
 > > (Admittedly it is also untidy that at least bulk-large cannot itself
 > > be "built" successfully, but until we're down to no more than a dozen
 > > or so routine failures I don't see this as terribly important.)
 > 
 > One thing I like about the meta-package approach is that it comes at
 > bulk building from a user PoV.

It was not, actually, the idea that you could do one of these partial
bulk builds by doing e.g. (cd meta-pkgs/bulk-medium && make update)
but I suppose it works. Sort of. Modulo the usual problems with
updating. :-/

 > I accept what Aleksey was saying about
 > the conflicting requirements - if there are any, I'd expect the list
 > of packages to be changed, though. And, as David says, this seems to be
 > a minor point.

Well, the immediate issue is that I put all three versions of Rails in
bulk-large, and they conflict with one another, so bulk-large can't
itself be built. This does not particularly hamper its use as a pbulk
target; it's only an annoyance. It's probably not the only such issue
either.

But it doesn't seem to me that updating the list to be conflict-free
is particularly desirable; maybe there's one version of Rails that's
recommended (I don't know, maybe someone can fill in here) but in
general, there are lots of things with multiple versions in pkgsrc, we
have those multiple versions for a reason, they're usually mutually
conflicting, and it doesn't necessarily make sense to pick exactly one
for this purpose.

-- 
David A. Holland
dholland%netbsd.org@localhost