On Sun, Apr 20, 2025 at 06:25:53PM +0100, Josh Triplett wrote: > On Sun, Apr 20, 2025 at 02:56:58PM +0300, Adrian Bunk wrote: > > On Thu, Apr 17, 2025 at 01:38:18PM -0700, Josh Triplett wrote: > > > Simon Josefsson wrote: > > > > Debian trixie images ship with 'mawk' pre-installed right now. While > > > > I'm not convinced the removal game is necessarily a good one, I can > > > > see that it does have some advantages. Is it possible to drop 'mawk' > > > > from the set of default tools in trixie? If not, what are the > > > > blockers? What is the method to find out what the blockers are? > > > > > > I would *love* to see the Essential set reduced. But I think this is > > > combining a couple of steps, and we'd do better to separate those steps. > > > > > > One is "should we make dependencies on awk explicit, rather than having > > > them be implicit and undocumented because awk is Essential". > > > The other is "should we reduce dependencies on awk". > > > > > > The latter may or may not happen in any individual case, but I think the > > > former would have a lot of value independently. > > > > The former without the latter is just a lot of wasted work without any > > benefits. > [...] > > > In general, I think this is roughly the right approach for any proposed > > > work on the Essential set, with the first step being to declare > > > dependencies explicitly. > > > > It's just a waste of time, especially if the end goal is not defined > > from the start. > > What I'm suggesting here is that if every individual package that needs > awk has a Depends on it (via a package that allows switching > implementations), rather than relying on Essential, then it becomes > possible to make incremental progress, and that incremental progress > benefits people who are willing to carefully remove some of what Debian > normally always has installed packages. > > If you're already building the kind of container that will want to > remove dpkg and apt (among other things) when you're done building it, > it'd be nice to have dependency metadata that helps you figure out what > is and isn't still used. That's useful even if not everything eliminates > its dependencies yet.
If you have no need to install security updates and want a really small system, then Debian is simply not the right choice. With embedded distributions a whole system of bootloader, kernel and userspace easily fits on 16 MB flash, even when including bloated stuff like glibc and systemd, with plenty of space left for the application that should run on the device. You can't do that with Debian. Being able to remove libsystemd0 would save multiple times of what you would save by removing AWK, your time would be better spent on requesting the creation of packages like util-linux-nosystemd instead of making dependencies on AWK explicit. Trying to save < 1% space by removing AWK in situations where Debian is anyway the wrong choice does not make much sense. > By way of example: e2fsprogs uses awk (in e2scrub), but many container > builders will remove that package (or never install it in the first > place), so it's not particularly important to do anything about its > dependency on awk, *other than declaring it*. If other, harder-to-remove > packages manage to stop using awk, then awk becomes removable, in a less > error-prone way. >... "harder-to-remove packages manage to stop using awk" is such awfully passive language. Let's rather talk about what Debian should officially support, and how Josh Triplett plans to implement it. Trying to officially support removing essential packages sounds to me like a maintainance nightmare with little benefit, you have to do some explaining how you will keep this maintainable when you do it. cu Adrian
