On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote: > I don't think such arguments are bringing us forward, > we should rather resolve the problem that these differ. > > All/Most(?) packages where they do differ are packages that were until > recently part of the essential set, and since debootstrap still installs > them they are in practice still part of the build essential set.
Sure. > Removing tzdata from the essential set made sense, and I do see your > point that tzdata does not fit the "totally broken" definition of > "required". > What we need are technical discussions like whether packages like tzdata > should also be removed from the build essential set, or whether tzdata > being a part of the build essential set should be expressed by making > the build-essential package depend on tzdata. I guess my question is, what makes tzdata build essential, besides that it's currently kind-of implicitly there? To me it does not look like it has the properties to be considered as such, besides that if we lower its priority (as it deserves) it makes a bunch of packages FTBFS. So, for one, this is getting in the way of making our minimal (non build) systems smaller. > I have so far not seen any technical arguments why removing tzdata from > the build essential set would be better for Debian than keeping it there. > Removing tzdata reduces the size of a chroot that has the build > dependencies for the hello package installed by ~ 0.5%, this size > decrease does not strike me as a sufficient reason for reducing the > build essential set. I don't see how this can be a pure technical decision, TBH. To me this looks more like either a matter of trade-offs, or IMO more importantly of clean definition of a specification (which seems rather more important than the other concerns). The work to spot these problems has already been done, and the changes required are trivial and minimal (disregarding any severity consideration here). > Everyone can feel free to disagree with me on the previous paragraph, > but please argue technically and not based on wording in policy. I can see the appeal, but the problem is that if we completely ignore policy, then we are starting from nothing, which means deciding over this is rather open-ended. And of course, policy is not set in stone and can be fixed, amended, extended as needed, but I think it's our base from where to start, so requesting to completely ignore it for this discussion seems not ideal? The current definition of what the build essential set is supposed to mean, from policy, seems rather easily mappable to actual package names (which was the intention, as to not hardcode those or their organization in policy itself): ,--- It is not necessary to explicitly specify build-time relationships on a minimal set of packages that are always needed to compile, link and put in a Debian package a standard “Hello World!” program written in C or C++. The required packages are called *build-essential*, and an informational list can be found in "/usr/share/doc/build- essential/list" (which is contained in the "build-essential" package). `--- Which maps to a C and C++ compiler (including linker and C library), make for debian/rules, and deb toolchain. I appreciate the minimalism and simplicity of the definition. I've also heard from time to time complains that we even require a C/C++ compiler as build-essential, when for many packages that's not even needed (although a C compiler is currently needed by dpkg-dev to determine the host arch). Policy also has this to say: ,--- If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships (including any implied relationships). […] `--- Given that "tzdata" does not fit into the "required" definition anyway, so the proposal to extend build-essential to include the "required" priority does not make sense; having to slap in there, that “oh BTW, in addition we also need timezone data, which is not going to be needed at all by that "Hello World!" program”, seems like a rather weird and gratuitous requirement, and hackish definition wise, just to avoid fixing those bug reports? There are many things we could also include in build-essential to avoid declaring them, which we still not do, so I'm not sure why we need to special case timezone data here. Regards, Guillem
