build deps/libs (was: Re: maintaining bulk-{small,medium,large})

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

hoping to centralize this discussion...

On Thu, Sep 14, 2023 at 11:42:42AM +0200, Thomas Klausner wrote:
 > I think none of f2c, libtool, mpfr, mpcomplex should be listed
 > explicitly.  If something pulls them in, fine, but it's not something
 > an end user will likely install (all of these are build dependencies).
 > [...]
 > If I stay consistent I'm against [ninja and meson] because they are
 > just build dependencies.  (At least these are more relevant than
 > libtool or f2c nowadays though.)

On Thu, Sep 14, 2023 at 08:34:50AM -0400, Greg Troxel wrote:
 > I don't understand why we want these things explicitly so I'm with wiz
 > here.  I think we should list things people actually want and build
 > tools get built as needed.

I don't agree. The reason bulk-small explicitly includes a number of
build tools and common libs is that if all you've got is a bulk-small
result, you're likely going to want to build a few more things. We
can't really anticipate which, or include all of them in the time
budget, but we can include the most common things they depend on or
need for building.

For this reason bulk-small currently has (explicitly) a bunch of
archivers and gmake, bison, flex, m4, autoconf, automake,
libtool-base, pkg_tarup, and x11-links, not to mention libiconv, db4,
gdbm, sqlite3, gettext-lib, readline, zlib, giflib, jpeg, png, tiff,
expat, xmlcatmgr, libxml2, libxslt, and gnutls.

One could debate whether all of those are really common enough to
warrant inclusion (particularly autoconf/automake, which are rarely
actually needed at build time and not super expensive to build) and
there are others equally common now (hence ninja and meson, and cmake
except it's too expensive) but I think the principle is sound.
(Obviously, since I wrote it this way in the first case ten years
back...)

I think the criterion should be "in this case, that is, the only
binary packages the user can get are from bulk-small, are the odds
that they'll end up wanting a copy of package A greater than they'll
end up wanting a copy of package B?". I think that warrants explicit
inclusion of the common build tools rather than including whatever the
list of end-user applications happens to depend on this week.

There's an assumption here that anyone operating in this environment
is voluntarily working on a slow or small machine and therefore
probably knows a fair amount about what they're doing. Which means
they _can_ build whatever they want, and the purpose of bulk-small is
to save them build time and disk wear.

For bulk-medium the situation is slightly different. On the one hand,
a bulk-medium result can reasonably be expected to have most of the
stuff one will want on a small end-user system; on the other hand, tbe
build budget is a lot larger and at some level the same principle
applies. There's still value to having tools and common libraries in
place. There are a handful of build tools listed, and a fair number of
common libraries, many of which are probably implicitly included by
the applications anyway. I think one of the original principles was
that it should include what you need to build smaller GUI
applications. I think another was "if the budget can afford it,
there's a reasonable chance of someone wanting it, and it's a nasty
build, it should go in", which is I think what motivated having boost.

Furthermore, with the gradual advent of working cross-compilation the
calculus changes somewhat. If we can cross-compile boost (whether that
works is anyone's guess) and provide the binary packages for slow
hardware, that prevents anyone from having to build it themselves on
that slow hardware (yes, they could set up their own cross-compile,
but that's not really for ordinary users) and that makes it worth
including, if it meets the time budget.

For bulk-large this is all silly; it is pretty much going to include
all common tools and libraries whether or not they're explicitly
listed, and I'd agree that the handful that are explicitly listed
should probably be dropped or reconsidered.

Anyway, that's the reasoning.

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