On Sat, Jan 28, 2023 at 07:34:48PM +0100, Guillem Jover wrote: > On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote: > > On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote: > > > Unsupported by whom? What is supported or unsupported is explained in > > > policy. > > > Policy says it must work. Therefore it should be supported (by fixing the > > > bugs). > > > > Policy §2.5: > > # "required" > > # Packages which are necessary for the proper functioning of the > > # system (usually, this means that dpkg functionality depends on > > # these packages). Removing a "required" package may cause your > > # system to become totally broken and you may not even be able to use > > # "dpkg" to put things back, so only do so if you know what you are > > # doing. > > As stated several times now this passage seems wrong, or inaccurate at > best. See #950440. And I don't see how tzdata would ever fall into > this definition even if that paragraph was correct. As mentioned > before, the tzdata package does not seem like a "required" package at > all, and this should be fixed by lowering its priority. Whether > debootstrap can be fixed to not use the Priority workaround, seem > orthogonal to the issue at hand. > > > > That's a straw man. I'm not proposing anything of the sort. Policy says > > > packages must build when essential and build-essential packages > > > are installed (plus build-dependencies). > > > > Build-essential _packages_. Not the "build-essential" package which very > > clearly says its dependencies are purely informational. > > It does not seem fair to argue both that the build-essential package is > just informational (when it's in fact the canonical declaration of what > is Build-Essential, and what every tool uses to install or check for the > Build-Essential package set), and then also argue that whatever > debootstrap installs (which is based both on build-essential plus a > workaround due to lack of proper dependency resolution) is the canonical > thing.
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. 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 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. Everyone can feel free to disagree with me on the previous paragraph, but please argue technically and not based on wording in policy. > Regards, > Guillem cu Adrian
