maintaining bulk-{small,medium,large}

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

It's been quite a while since the overall lists in these packages were
reviewed. (There have been assorted incremental changes, but most of
them have been just to track version updates of one kind or another.)

At the initial prodding of gdt@ and after having then discovered some
really serious anachronisms, I've gone over the whole thing and have a
batch of proposed changes/updates.

Note that churn in these packages doesn't accomplish anything. The
goal is to keep them useful. Recall: the purpose of each size is to
produce a broadly useful set of packages in a limited amount of build
time. This includes both packages that are directly useful to users
and also packages that are widely used by other packages, so that if
someone needs something that isn't included and therefore needs to
build it they aren't starting at absolute zero.

Also recall that they're supposed to be monotonic, that is, bulk-large
depends on bulk-medium depends on bulk-small so that everything in one
is also in the larger ones.

When things were set up the intended build time quotas were, on a fast
build machine:
   - bulk-small: one hour
   - bulk-medium: eight hours
   - bulk-large: 24 hours

The expectations one might reasonably have for a fast build machine
have increased a good deal; but on the other hand the slowest machines
people use netbsd and/or pkgsrc on haven't gotten any faster, and part
of the point has been to give standard subsets that can be built on
slower targets without taking all kinds of forever.

Point for discussion: are these time quotas still reasonable? Does
anyone have recent data points on how long any of these packages take
(that is, each whole package set, not the meta-package itself, which
is ~free) on either fast build machines or slow machines?

Issues and proposed changes follow.


1. Emacs. When these packages were first set up, bulk-small had
emacs22, bulk-medium had emacs23, and bulk-large had emacs24.
Incremental maintenance has produced the current situation where
bulk-small has emacs21, and both bulk-medium and bulk-large have
emacs26. I forget exactly why we had both 23 and 24, but emacs
releases have been a lot less problematic in recent years (AFAICT) and
I think we (a) don't need two different modern emacs versions, (b)
don't need the same version listed in both bulk-medium and bulk-large,
and (c) it should indirect via the editors/emacs meta-package so it
always builds the current recommended version. (However, there should
still be a pre-emacs23 version in bulk-small for use on small
systems.)

Note that bulk-medium also includes xemacs (via xemacs-packages) and I
don't propose to change that.

Proposal: take the explicit emacs entry out of bulk-large and change
bulk-medium to be editors/emacs instead of editors/emacs26.


2. Python. We currently have python 3.8 in bulk-small and python 3.10
in bulk-medium. This seems like bitrot. Originally bulk-small had
python2 and bulk-medium had python3; at the time this made a certain
amount of sense. However, nowadays python2 is dead except for very
specialty purposes and doesn't belong in any of the bulk-* packages;
and it is, for the most part, not necessary for most people to have
more than one python3. Plus the particular versions we have seem the
result of sporadic maintenance rather than any conscious choice. I
don't remember if there's some technical reason we don't automatically
track PYTHON_VERSION_DEFAULT (if anyone knows, speak up) but I think
we should assume that the python version in bulk-* should be, at least
most of the time, the same as PYTHON_VERSION_DEFAULT, and we don't
need more than one.

Proposal: change bulk-small to have python 3.10 and drop explicit
listing of python in bulk-medium.


3. Fortran. Currently bulk-small includes f2c as a dep of
libtool-base, which hasn't been true for a minor eternity. This should
be removed. What I'm less clear on is whether f2c is still a useful
configuration for a small system (in which case it should go in
-medium) or not (in which case it should be removed entirely). Please
discuss. Meanwhile, the gcc one currently needs to build fortran
packages (whatever it is at any given time) implicitly appears in
-medium because -medium includes blas and lapack. Should these be
moved to -large? Please also discuss. See point below under Rust about
-medium's time budget. Also, should it be listed explicitly? I kind of
think so. (Relatedly, gmp should be moved to be with it from where
it's currently in bulk-large, and mpfr/mpcomplex should be added in as
well, since gcc depends on those anyway.)

Proposal: TBD


4. ghostscript. Currently ghostscript-gpl is in bulk-small and
ghostscript-agpl is in bulk-medium. While some things that probably
shouldn't still depend on ghostscript (e.g. ImageMagick, and assorted
bits of TeX) for the most part its importance as a dep of other things
has dropped sharply in the past ten years and I don't think it belongs
in -small any more, especially since it's not that cheap to build. The
question then is whether we need both copies. I'm inclined to think
not, but the licensing mess is vexing and not something I really want
to wade into at the moment.

Proposal: move ghostscript-gpl to bulk-medium. Also drop its deps from
bulk-small.


5. lcms (not lcms2). Currently bulk-medium has both lcms and lcms2.
Not that much uses lcms 1 any more, and I think it's reasonable to
drop it from bulk-medium.

Proposal: drop lcms from bulk-medium.


6. Newer build tools. I think ninja and meson should get added to
bulk-small. This also involves adding py-setuptools, which we should
probably have in there anyway, and py-expat, which is harmless. All
of these together are a lot less build than ghostscript-gpl.

Proposal: Add these to bulk-small.


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.


8. Other stuff in bulk-large. I observe the following in bulk-large
that quite possibly should get changed:
   - gstreamer1, which I think is mostly no longer relevant these days?
   - both heimdal and mit-krb5, which seems gratuitous
   - squirrelmail but not roundcube (don't a lot more people use roundcube?)
Please discuss, not really on top of these issues myself.

Proposal: TBD


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