On Sun, Apr 20, 2025 at 10:56:49PM +0300, Adrian Bunk wrote: > 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
You said this elsewhere in the thread, but it's not correct there or here: you absolutely *do* install security updates for a container, by installing a new container with new versions of packages. > With embedded distributions a whole system of bootloader, kernel and > userspace Containers typically don't have either a bootloader or a kernel, and often don't have an init either. > > 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. I would be more than happy to work on it, in collaboration with others proposing such changes. I expect that such work consists of 10% doing careful archive-wide scans to detect usage of packages, 10% writing tooling, 5% writing relatively small patches, and 75% discussion threads having to defend the value of such work from people who have no interest in working on it themselves but spend a lot of energy telling other people it's a waste of time. I would also be thrilled to write patches to Policy, establishing a very clear process for *carefully* reducing the Essential set in step-by-step ways. For instance, I'd try to revive a past Policy patch I wrote adding an exception to the policy against depending on Essential packages. And personally, I'd likely start by putting together a `dh-shelldeps`, which parses shell the way that things like shellcheck does, does a rough approximation of "what is every program invoked by every shell script in the package", and looks that up in `shelldeps` metadata analogous to `shlibdeps`. > 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. I expect it'll be maintained in much the same way most features in Debian are maintained: the people who use it will submit patches, report bugs when it doesn't work, and if they spend too much time reporting those bugs or find it breaking more often than they'd like, they'll implement more tooling (e.g. lintian checks, archive scans). Right now, by way of example, if your package needs tzdata, and you fail to depend on it, and because you have that package installed you don't happen to notice, and you don't have autopkgtests that exercise that part of the code, then there's very little to catch that. I don't think this will be any worse than that, in practice, and we already deal with that for e.g. `Priority: important` packages without substantial issues.
