Re: MBF: Packages which break with nocheck

[Paul Gevers]

Hi,

On 16-04-2025 19:59, Santiago Vila wrote:

I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck
for the second build, I think it would help. I don't think anybody will
use that as an excuse to file more RC bugs.



They mentioned earlier on IRC that they'll do just that *after* trixie 
release.


Paul



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: MBF: Packages which break with nocheck

[Santiago Vila]

El 17/4/25 a las 9:21, Paul Gevers escribió:

Hi,

On 16-04-2025 19:59, Santiago Vila wrote:

I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck
for the second build, I think it would help. I don't think anybody will
use that as an excuse to file more RC bugs.


They mentioned earlier on IRC that they'll do just that *after* trixie release.


Yes, I know that they plan to do that after trixie, but they also said this
in the RB mailing list as their rationale:


the release team doesnt want hundreds of RC bugs filed based on these failures
right now


which seems a strange rationale to me given that they are neither hundreds nor 
RC.

Thanks.

Re: MBF: Packages which break with nocheck

[Holger Levsen]

On Thu, Apr 17, 2025 at 09:45:53AM +0200, Santiago Vila wrote:
> > > I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck
> > > for the second build, I think it would help. I don't think anybody will
> > > use that as an excuse to file more RC bugs.
> > They mentioned earlier on IRC that they'll do just that *after* trixie 
> > release.
> Yes, I know that they plan to do that after trixie, but they also said this
> in the RB mailing list as their rationale:
> > the release team doesnt want hundreds of RC bugs filed based on these 
> > failures
> > right now
> which seems a strange rationale to me given that they are neither hundreds 
> nor RC.

the reproducible builds folks have also 100s of other issues on their plates
and only this many spoons.

enabling nocheck now, takes time and attention, and frankly is not really
that much related to our core mission, it's just one of the many corners
where we already do a lot of qa work and where we could do even more.

time and attention are our most scare ressources.

HTH.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Menschen, die sich um die Klimakatastrophe sorgen, sind keine Klimaaktivisten
und auch nicht woke. Sie haben schlicht die Fähigkeit einen Wissenschaftlichen
Befund zu lesen und zu verstehen. (@DGlatzkopp)


signature.asc
Description: PGP signature

Re: Bug#1100677: Pending autoremoval of debian-reference* packages

[Osamu Aoki]

Hi,


I now see this as a bug.  I think this was caused by my post-bookworm change in 
debian-reference (2.109) on Mon, 18 Dec 2023.

If I remember correctly, the intent of this change was to move all
HTML/PDF/Plain_Text document to a path under /usr/share/doc/ for better policy
compliance.

This regression was partly addressed in debian-reference (2.114) by closing
#1063590 on Sat, 10 Feb 2024. What is reported is the remaining issue.

So the question is the best known method to mitigate potential upgrade problem.

I now understand "adding Conflicts or upgrading the versioned dependency on
debian-reference-common to a Pre-Depends" is one way.

Before doing it, I would like to know the best established method.

How about adding simpler versioned depends (no pre-depends) with pre-rm script?
Isn't it simpler?

Or is there any other simpler and cleaner established solution. (A pointer to a
package using such trics will be good for me.)

Any suggestion?

Osamu


On Sun, 2025-04-13 at 16:08 +0200, textsh...@uchuujin.de wrote:
> I belive debian wants to provide its documentation as packages in stable
> releases.
> 
> But currently debian-reference is scheduled for auto removal on 2025-04-15
> (which this mail bumps a bit into the future).
> Maybe "nobody" is aware of this?
> 
> Anyone up to taking a look at this?
> 
> On Mon, 17 Mar 2025 08:14:02 +0100 Helmut Grohne  wrote:
> > Package: debian-reference-de,debian-reference-en,debian-reference-es,debian-
> > reference-fr,debian-reference-id,debian-reference-it,debian-reference-
> > ja,debian-reference-pt,debian-reference-pt-br,debian-reference-zh-cn,debian-
> > reference-zh-tw
> > Version: 2.125
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: fileconflict
> > Control: affects -1 + debian-reference-common
> > 
> > The debian-reference packages have a tricky undeclared file conflict
> > that may break bookworm to trixie upgrades. In bookworm,
> > debian-reference-common contains a symlink
> > /usr/share/doc/debian-reference-common/docs pointing to
> > ../../debian-reference whereas the debian-references-* packages in
> > trixie install the same location as a directory. On the face of it, this
> > is an undeclared file conflict. Really though, a bad unpack order can
> > cause the unpack of the trixie files to be redirected and then go
> > missing as this is a symlink to directory conversion moving between
> > packages. The debian-refefence-* packages really need to prevent
> > concurrent unpack with bookworm's debian-reference-common. Breaks and
> > Replaces is not sufficient here. I think the options basically are using
> > Conflicts or upgrading the versioned dependency on
> > debian-reference-common to a Pre-Depends (requires consultation with
> > d-devel). The latter option is a larger hammer and prevents a weird
> > corner case that is not covered by Conflicts.
> > 
> > Helmut
> 

Re: Bug#1100677: Pending autoremoval of debian-reference* packages

[Osamu Aoki]

Hi,

Following up on my previous post.

> How about adding simpler versioned depends (no pre-depends) with pre-rm
> script?

I am talking about tricks using the "dpkg-maintscript-helper symlink_to_dir ..."
command.  Any thought?


Osamu


On Thu, 2025-04-17 at 20:40 +0900, Osamu Aoki wrote:
> Hi,
> 
> 
> I now see this as a bug.  I think this was caused by my post-bookworm change
> in 
> debian-reference (2.109) on Mon, 18 Dec 2023.
> 
> If I remember correctly, the intent of this change was to move all
> HTML/PDF/Plain_Text document to a path under /usr/share/doc/ for better policy
> compliance.
> 
> This regression was partly addressed in debian-reference (2.114) by closing
> #1063590 on Sat, 10 Feb 2024. What is reported is the remaining issue.
> 
> So the question is the best known method to mitigate potential upgrade
> problem.
> 
> I now understand "adding Conflicts or upgrading the versioned dependency on
> debian-reference-common to a Pre-Depends" is one way.
> 
> Before doing it, I would like to know the best established method.
> 
> How about adding simpler versioned depends (no pre-depends) with pre-rm
> script?
> Isn't it simpler?
> 
> Or is there any other simpler and cleaner established solution. (A pointer to
> a
> package using such trics will be good for me.)
> 
> Any suggestion?
> 
> Osamu
> 
> 
> On Sun, 2025-04-13 at 16:08 +0200, textsh...@uchuujin.de wrote:
> > I belive debian wants to provide its documentation as packages in stable
> > releases.
> > 
> > But currently debian-reference is scheduled for auto removal on 2025-04-15
> > (which this mail bumps a bit into the future).
> > Maybe "nobody" is aware of this?
> > 
> > Anyone up to taking a look at this?
> > 
> > On Mon, 17 Mar 2025 08:14:02 +0100 Helmut Grohne  wrote:
> > > Package: debian-reference-de,debian-reference-en,debian-reference-
> > > es,debian-
> > > reference-fr,debian-reference-id,debian-reference-it,debian-reference-
> > > ja,debian-reference-pt,debian-reference-pt-br,debian-reference-zh-
> > > cn,debian-
> > > reference-zh-tw
> > > Version: 2.125
> > > Severity: serious
> > > User: debian...@lists.debian.org
> > > Usertags: fileconflict
> > > Control: affects -1 + debian-reference-common
> > > 
> > > The debian-reference packages have a tricky undeclared file conflict
> > > that may break bookworm to trixie upgrades. In bookworm,
> > > debian-reference-common contains a symlink
> > > /usr/share/doc/debian-reference-common/docs pointing to
> > > ../../debian-reference whereas the debian-references-* packages in
> > > trixie install the same location as a directory. On the face of it, this
> > > is an undeclared file conflict. Really though, a bad unpack order can
> > > cause the unpack of the trixie files to be redirected and then go
> > > missing as this is a symlink to directory conversion moving between
> > > packages. The debian-refefence-* packages really need to prevent
> > > concurrent unpack with bookworm's debian-reference-common. Breaks and
> > > Replaces is not sufficient here. I think the options basically are using
> > > Conflicts or upgrading the versioned dependency on
> > > debian-reference-common to a Pre-Depends (requires consultation with
> > > d-devel). The latter option is a larger hammer and prevents a weird
> > > corner case that is not covered by Conflicts.
> > > 
> > > Helmut
> > 
> 

Dropping awk?

[Simon Josefsson]

Hi

I noticed that Fedora 42 was released and their docker images lack a
'awk' tool.  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?

/Simon


signature.asc
Description: PGP signature

Re: Dropping awk?

[Colin Watson]

On Thu, Apr 17, 2025 at 08:40:42PM +0200, Santiago Vila wrote:

Installed size of mawk is 263 MB which is really small for today's standards.


KB rather than MB, thankfully!

--
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1103430: ITP: jmh -- harness for building, running, and analysing Java benchmarks

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-Java team 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-j...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jmh
  Version : 1.37
  Upstream Contact: OpenJDK Community
* URL : https://openjdk.org/projects/code-tools/jmh/
* License : GPL-2
  Programming Lang: Java
  Description : harness for building, running, and analysing Java benchmarks

JMH is a Java harness for building, running, and analysing
nano/micro/milli/macro benchmarks written in Java and other languages
targeting the JVM.

The recommended way to run a JMH benchmark is to use Maven to setup a
standalone project that depends on the jar files of one's application. It is
possible to run benchmarks from within an existing project, and even from
within an IDE, however setup is more complex and the results are less
reliable.

In all cases, the key to using JMH is enabling the annotation- or
bytecode-processors to generate the synthetic benchmark code. Maven archetypes
are the primary mechanism used to bootstrap the project that has the proper
build configuration.

The classes of JMH are used by many testsuites in Debian.
I aim to maintain it in the Debian-Java team.

-BEGIN PGP SIGNATURE-

iQJDBAEBCgAtFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmgBBGcPHHBndEBkZWJp
YW4ub3JnAAoJEGADFqbcJ3R238QP/AxQaYmyR/VwL+5CgVknMu7Dn9P/cuYKvgAF
yZPgL6ncwNesaHTM6FjtVuS0tNpZXpCLwKOSBiA2nfnP2CHzJyf01unLeS0Q7YSC
EjdDMXvVgIDAeknfl9OD0cPVgERCwzZO9vG1pzWj3493aLuEFGK2wuITdYP6w6at
Ky3Ic6dXHC5q6LQs3uWN54IR/malQtMPkBfAIAmhU0LyuWo65pKgcsjInlXAQPpw
BGfPNdKuWBRtP07Ki7g0VEL2WLwsE/xFnTHNa5erBi+1Tgte//KqS2FqJzFxKK8i
RVkKjEZwTekCrnemuUDlmh5a4RqZmTHmmVbLMmLLpEwIUM/s7Gz4T/7hOQcYrVF1
jmHb7OO+2JFTd+ESe32V6dLTpAxAfA8gbQHrKvcof7AuwD9WWOBKTUd/Wg+B1m9X
oaw1LvyCwrJzGY5n8+8rZ0ER5UG9v9jbbUit3dvXAPKapEGNTRLsgbvtp+CclE97
StwD0GG2mrtopLJ4ybfDSW6DGzCQDDI0Q5mwtGsHs3Md6tqF36emG0pjgTTC516i
lwJqQOcQ7PxTUigH5uJ76FrmJM54M1TFVQgMDIUeLj2tH9Hrpnf6aCIBesOow6p8
UXF4LFZh6QrRcjKJg5pBPoZHeusIjfScVlFacZFN0t4U6NsVuZ6a1FW1IQvV/3HU
NxUQoi1k
=Rc36
-END PGP SIGNATURE-

Re: Dropping awk?

[Tianon Gravi]

On Thu, Apr 17, 2025 at 03:51:15PM -0400, Paul Tagliamonte wrote:
> On Thu, Apr 17, 2025 at 11:27:22AM -0700, Russ Allbery wrote:
> > awk is in the essential set in Debian, so this would be a very substantial
> > amount of work.
>
> {Docker image comaintainer hat on}
>
> This is right. More specifically -- the Debian docker images are
> (intentionally) -- "just" `debootstrap --variant=minbase`.
>
> Changing what packages are "pre-installed" with the Docker image is not a
> negotiation that we wanted to have in isolation as the people who keep
> the image current. Our goal was to have an image that wasn't unique (or
> suprising) to a Debian project member -- rather, IMVHO, the package(s)
> should be added or removed from the minbase set via our usual conventions.
>
> This has come up from time to time (in the form of some people asking to
> 'please install X', or 'why did Y go away') -- but the result and push to
> sync these two ecosystems (debootstrap and the image) is something I believe
> to be correct, and don't have any real intention of changing as of right
> now.
>
> If we want to drop something from the Docker image -- that's great! I'd love
> that. It's just something we'd have to work through the usual process of
> changing priority, deps, or what have you. Which -- I will note -- benefits
> the whole operating system on all platforms, not just one container image
> (this is the way).

Co-sign all of that, with the addition of the following interesting
links:

- https://salsa.debian.org/debian/grow-your-ideas/-/issues/20
  (where shrinking is discussed before / still)

- 
https://github.com/debuerreotype/docker-debian-artifacts/blob/949bf2c69b0888b62fe78dd45d02b74a7ddf64e2/trixie/rootfs.manifest
  (the current set of packages in the "debian:trixie" image)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

(please keep me CC'd in any replies; I don't subscribe to -devel)


signature.asc
Description: PGP signature

Re: I cannot upload since yesterday

[Salvo Tomaselli]

> I uploaded on Monday using the ssh-upload target. Have you tried that
> one?

No I just tried regular dput, but it seems to have started working again now.



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

signature.asc
Description: This is a digitally signed message part.

Re: Dropping awk?

[Helmut Grohne]

Hi Simon,

On Thu, Apr 17, 2025 at 08:23:18PM +0200, Simon Josefsson wrote:
> I noticed that Fedora 42 was released and their docker images lack a
> 'awk' tool.  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?

shrinking essential/minbase/container images generally is a worthwhile 
goal as you saw from existing replies. What is not as useful is asking 
"can we drop XXX?" with little context, because (as others indicated) 
this is a ton of work.  The way to advance these matters is doing 
research.

One of the first aspects is what "dropping" means. Typical answers:
 * Removing "Essential: yes"
   * e2fsprogs, mount and a few more used to be essential.
 * Removing dependencies
   * apt (not essential, but close) used to depend on adduser.
 * Reducing the Priority value
   * We've been debating this for ifupdown.
 * Removing dependencies within the build-essential set
   * I recently proposed removing libcrypt-dev from build-essential.

In this case, the immediate meaning must be getting it out of essential. 
However, that does not move it out of container images, which incurs 
further work and also raises the user impact (see Sean's mail).

Next, there is a question of what we gain. Essential weighs in at 
roughly 100MB (depending on how you count it). So regarding awk, we're 
talking about a size reduction of about 0.3%. For comparison, being able 
to substitute toybox for coreutils has the potential to reduce more than 
10% of size. Removing bash (keeping dash) would be around 7%. Whilst 
those other gains are significantly higher, their impact and effort also 
is. Picking a sensible candidate is the difficult part here.

It leads us to analyzing the effort and impact. Being in the essential 
set means that dependencies are not spelled out. So the first step is 
locating those dependencies. As we will likely not be able to audit 
Debian's source code for awk uses in a reasonable amount of time, 
empirical methods are likely needed.
 * Rebuild the archive with awk dropped and see what fails
 * Consider using reproducible builds to additionally see what packages
   change as a result of dropping awk (for those that happen to be 
   reproducible)
 * Search for awk usage in maintainer scripts
   https://binarycontrol.debian.net/?q=awk&path=unstable%2F.*%2Fp
   Note that postrm scripts cannot express dependencies and need to be 
   rewritten without awk. It also means that if you assume people to 
   always purge their packages, we may remove awk in forky+1 at best if 
   we manage to fix all postrm in forky.
 * Download all Debian binary packages and search for awk uses in the 
   installed files using regular expressions.
 * Run autopkgtests with awk removed

Doing this is a ton of work. Doing that work and presenting the results 
is what makes "can we drop awk?" a useful question as it answers the 
cost part.

This is not meant to discourage you. Quite to the contrary. Reducing 
implicit software dependencies has lots of other benefits such as easing 
architecture bootstrapping and a smaller trusted computing base. It is a 
topic you cannot do in a spare evening though.

For instance, I'd like to propose making coreutils substitutable in 
essential like awk is substitutable. However, that question is not 
presently "useful" in the sense that it lacks a sound implementation.  
I've been pondering this with Jochen and Johannes back in Würzburg and 
now Julian has picked up the question and arrived at a promising 
prototype based on feedback from Guillem. I hope that we are discussing 
coreutils soon, but that discussion will be so much more useful when it 
comes with a prototype and an impact analysis.

Helmut

Re: Dropping awk?

[Samuel Henrique]

On Thu, 17 Apr 2025 at 19:41, Santiago Vila  wrote:
> Installed size of mawk is 263 MB which is really small for today's standards.

Isn't that bad for the Debian minimal images for containers?

I'm not too familiar with how we generate our container images but I can see
mawk there and Debian is used on most official container images of other
projects.

Cheers,


-- 
Samuel Henrique 

Re: POSIX sh compatibility (Re: Dropping awk?)

[Richard Laager]

On 2025-04-17 19:44, Sean Whitton wrote:

m4 is the only way POSIX.1-2017 defines to safely create a temporary
file (outside of writing and compiling a C program).


I was not aware of using m4 for this, so that piqued my interest.


I think the newer
POSIX standard has not improved on this particular point.


It seems it has not.

Adding mktemp(1) to POSIX has been proposed:
https://www.austingroupbugs.net/view.php?id=1616

See also:
https://unix.stackexchange.com/questions/614808/why-is-there-no-mktemp-command-in-posix

Especially the quote from Geoff Clare: "However, I don't know how 
widespread support for the new mkstemp() macro is."


https://mywiki.wooledge.org/BashFAQ/062#Using_m4 says, "For example, the 
m4 in MacOS (July 2021) was too old to have the mkstemp macro included."


I tested on macOS Sonoma 14.4.1 just now, and m4 is broken for me. That 
said, I might have a broken installation of Xcode developer tools on 
this system. It's unclear to me if m4 requires Xcode developer tools 
normally or what. Installing them was estimating 21 hours, so I didn't 
do that.


So, personally, I think getting mktemp(1) added to POSIX would be better 
for portability in the long run anyway.


--
Richard



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Dropping awk?

[Russ Allbery]

Simon Josefsson  writes:

> I noticed that Fedora 42 was released and their docker images lack a
> 'awk' tool.  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?

awk is in the essential set in Debian, so this would be a very substantial
amount of work. See the Pre-Depends in base-files, which is there to make
some awk implementation essential while still allowing the user to switch
between implementations.

-- 
Russ Allbery (r...@debian.org)  

Bug#1103477: ITP: ffuf -- Fast web fuzzer written in Go

[Facundo Acevedo]

Package: wnpp
Severity: wishlist
Owner: Facundo Acevedo 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name    : ffuf
  Version : 2.1.0-1
  Upstream Author : https://github.com/ffuf
* URL : https://github.com/ffuf/ffuf
* License : Expat
  Programming Lang: Go
  Description : Fast web fuzzer written in Go
  Command-line tool for discovering resources in web applications.

Re: Dropping awk?

[Paul Tagliamonte]

On Thu, Apr 17, 2025 at 11:27:22AM -0700, Russ Allbery wrote:

awk is in the essential set in Debian, so this would be a very substantial
amount of work.


{Docker image comaintainer hat on}

This is right. More specifically -- the Debian docker images are
(intentionally) -- "just" `debootstrap --variant=minbase`.

Changing what packages are "pre-installed" with the Docker image is not 
a negotiation that we wanted to have in isolation as the people who keep
the image current. Our goal was to have an image that wasn't unique (or 
suprising) to a Debian project member -- rather, IMVHO, the package(s) 
should be added or removed from the minbase set via our usual 
conventions.


This has come up from time to time (in the form of some people asking to
'please install X', or 'why did Y go away') -- but the result and push 
to sync these two ecosystems (debootstrap and the image) is something I 
believe to be correct, and don't have any real intention of changing as 
of right now.


If we want to drop something from the Docker image -- that's great! I'd 
love that. It's just something we'd have to work through the usual 
process of changing priority, deps, or what have you. Which -- I will 
note -- benefits the whole operating system on all platforms, not just 
one container image (this is the way).


  paultag

--
  ⢀⣴⠾⠻⢶⣦⠀   Paul Tagliamonte 
  ⣾⠁⢠⠒⠀⣿⡁  https://people.debian.org/~paultag | https://pault.ag/
  ⢿⡄⠘⠷⠚⠋Debian, the universal operating system.
  ⠈⠳⣄⠀⠀  4096R / FEF2 EB20 16E6 A856 B98C  E820 2DCD 6B5D E858 ADF3


signature.asc
Description: PGP signature

Re: Dropping awk?

[Santiago Vila]

El 17/4/25 a las 20:27, Russ Allbery escribió:

Simon Josefsson  writes:


I noticed that Fedora 42 was released and their docker images lack a
'awk' tool.  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?


awk is in the essential set in Debian, so this would be a very substantial
amount of work. See the Pre-Depends in base-files, which is there to make
some awk implementation essential while still allowing the user to switch
between implementations.


Indeed. As James Troup once said, we made perl to be part of the essential set,
and not doing the same with good old awk would be criminal.

Installed size of mawk is 263 MB which is really small for today's standards.

Thanks.

Re: Dropping awk?

[Josh Triplett]

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. And with the former
done, we'd have the opportunity to *consider* the latter on a
case-by-case basis, with rationales like "if packages A and B didn't use
awk, then we'd simplify bootstrapping", or "if packages B and C didn't
use awk, it'd be possible for XYZ useful class of minimal
systems/containers/VMs to not need it installed".

Given some amount of agreement that it had value, and that the downsides
were low, we could consider *starting* to list dependencies on awk (by
way of virtual packages to allow selecting implementation) explicitly,
rather than leaving them implicit via Essential. A quick look at
/var/lib/dpkg/info suggests that not *that* many maintainer scripts use
it even on a full desktop system, and a look at /usr/bin and /usr/sbin
suggests that while there are various things using it, they tend to come
in a few broad categories (e.g. developer-oriented scripts) and *mostly*
be higher in the stack (e.g. mostly not essential things themselves). (A
notable exception is tzselect, which makes extensive use of awk, but
while that's in the essential package libc-bin, it does not itself seem
like an essential tool and could potentially be in a higher-level
package itself.)

Based on that, it seems like it would not be *especially* hard to
*declare dependencies* on awk, which would not in any way a commitment
towards *systematically eliminating* those dependencies. Having those
dependencies declared would then make it feasible to consider avoiding
it in *some* especially valuable cases, and conversely would allow folks
building container/VM/embedded images to know when they actually need
it.

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.

- Josh Triplett

Re: POSIX sh compatibility (Re: Dropping awk?)

[Sean Whitton]

Hello,

On Thu 17 Apr 2025 at 08:02pm -05, Richard Laager wrote:

> So, personally, I think getting mktemp(1) added to POSIX would be
> better for portability in the long run anyway.

Eventually.  POSIX.1-2017 is going to be the thing to target for a long
time, I think.

GNU m4 doesn't follow POSIX strictly, unfortunately.

See these workarounds for both the potential lack of m4 and the lack of
GNU m4 behaving POSIXly:

  https://sources.debian.org/src/consfigurator/1.2.3-1/src/connection.lisp/#L305

-- 
Sean Whitton


signature.asc
Description: PGP signature