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

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

Updates, since I've been hacking things:

On Thu, Sep 14, 2023 at 08:27:07AM +0000, David Holland wrote:
 > 1. Emacs. [...]
 > 
 > Proposal: take the explicit emacs entry out of bulk-large and change
 > bulk-medium to be editors/emacs instead of editors/emacs26.

A wrinkle appeared, which is that (modern) emacs turns out to
indirectly depend on rust, I think via libimagequant. So the
resolution of this is:
   - bulk-large contains editors/emacs
   - bulk-medium contains editors/emacs-nox11
   - bulk-small continues to contain emacs21

This also requires that emacs-packages only goes in bulk-large,
because without the ability to set EMACS_TYPE to a nox11 version, it
pulls in the x11 emacs and then also rust. I don't think this is a
serious problem.

Note also that xemacs (with x11) remains in bulk-medium.

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

This has been done, except it's 3.11. I haven't done anything to track
PYTHON_VERSION_DEFAULT directly, and maybe that should happen too.

 > 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.

I dropped f2c. If anyone thinks it should go in -medium, let me know.

 > 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.)

This has not been resolved. For the time being -medium will still be
building gcc. I am not sure this fits within its intended time budget,
but it's at least possible that it might.

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

As suggested, ghostscript is in bulk-medium now, and via the
meta-package. The net practical effect of this, if nobody does
anything special, is that the resulting build will build
ghostscript-agpl and not ghostscript-gpl. Given how old and unsafe
ghostscript-gpl is, this seems like a reasonable resolution, despite
the various problems with the AGPL.

(Realistically to the extent that licensing is a problem, the answer is
to work on further disentangling ghostscript from things that don't
need to use it. Since ~all distributed documents come as PDF and have
for decades, the only place ghostscript _should_ appear is in the
backend printing pipeline, or in printer firmware. It shouldn't need
to be linked into or run from any application other than perhaps gv as
a viewer for legacy documents. But I digress...)

 > 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.

Done.

 > 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.

As noted, they've actually de facto been in there for some time, so I
went ahead.

 > 7. Rust. [...]

Everything that was bringing in rust has been moved to bulk-large.

 > [cmake]

Everything in bulk-small that was bringing in cmake has been moved to
bulk-medium, on the grounds that bulk-small really does not have the
time budget to build cmake.

Unfortunately this resulted in punting apache and both window
managers. While there's still bozohttpd on the www front, there really
ought to be a window manager in -small; anyone have any suggestions?

 > (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.)

I think the conclusion is that there isn't any automated way and that
someone should run "make build-depend-list | grep rust" periodically.

 > 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

Nobody's said anything about this at all so I haven't done anything.

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