El 4/1/23 a las 17:16, Russ Allbery escribió:
But if you are building new Debian packages, by definition you are not in a tiny minimal system case. build-essential is already somewhat arbitrary and chosen for convenience (most packages do not require a C++ compiler). Why not expand build-essential to what we're largely doing in practice to fix the consistency problem (which is a real issue) but not add work tweaking build dependencies for a bunch of packages?
A minimal build essential set provides and generates useful information that a build essential set which is not so minimal does not provide. For example, some packages have unit tests which depend on the information stored on tzdata. In some cases, changes in tzdata causes those unit tests to fail. The tzdata package is updated often in stable. If we were to know in advance what packages could break, we could look at the packages which build-depend on it, either directly or indirectly. If we don't have such information, we can't even try to do that. So, a minimal build essential set has the same benefits as a minimal essential set, namely, that we know a lot better which are the real build-dependencies or the real dependencies, as they are not hidden. Thanks.