Re: maintaining bulk-{small,medium,large}

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

On Thu, Sep 14, 2023 at 08:27:07AM +0000, David Holland wrote:
 > 7. Rust. The browser in bulk-medium got changed to arcticfox, which
 > apparently doesn't depend on rust, but currently bulk-medium will
 > still bring in rust via librsvg, which is listed explicitly, and also
 > py-cryptography, which isn't. Rust is basically too big for
 > bulk-medium; it alone will take a large fraction of the notional time
 > budget, if not all of it. Should all the rust users get punted to
 > bulk-large? I'm inclined to think so. Please discuss.
 > 
 > Keep in mind that (as noted above) bulk-medium includes a gcc build in
 > order to provide fortran support, not to mention boost, and that's
 > already plenty long enough.
 > 
 > (If we do punt rust users, I'm also inclined to take some steps to
 > crosscheck that rust doesn't creep back in by accident, though I'm not
 > sure what. We don't really have a good way to do that.)
 > 
 > Proposal: TBD.

It is worse than this. Currently rust is implicitly in bulk-small. I
think this is a consequence of libimagequant, which is included by
graphics/gd.

Since there is _definitely_ not room for rust in bulk-small, gd has to
go. Whether it gets moved to bulk-medium or bulk-large depends on the
resolution of the above...

(Also, it seems that ninja and meson are already implicitly pulled in
by bulk-small, so adding them is only regularizing the existing
situation. And as a consequence, it currently actually has both
python38 and python310, which is really silly.)

(However, it seems that cmake is getting pulled in as well, and I
think that violates the time budget and we need to reconsider whatever
packages are using it, which I haven't tracked down yet.)

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