POSIX sh compatibility (Re: Dropping awk?)
Hello, On Thu 17 Apr 2025 at 03:51pm -04, Paul Tagliamonte wrote: > 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 makes sense. In this vein, I wish that our minimal install was POSIX sh-compatible. It currently isn't, because m4 isn't included (and maybe some other things). In fact, even on a regular Debian desktop install, m4 isn't there unless you explicitly install it. m4 is the only way POSIX.1-2017 defines to safely create a temporary file (outside of writing and compiling a C program). I think the newer POSIX standard has not improved on this particular point. Removing awk from default installs would move us further away from that. I don't know how common my view is, but I think making sure that all POSIX sh-compatible scripts could be guaranteed to run without compatibility hacks on any *BSD, macOS or Debian-based system would be fantastically useful (at least FreeBSD and macOS already have the full POSIX sh suite out-of-the-box; I would assume the other BSDs do too). I think the implementation of this does not need to be "Essential: yes", btw. Making it possible to be even smaller is fine too. I'm talking about defaults -- and I think that includes default/official container images. -- Sean Whitton signature.asc Description: PGP signature
Re: Dropping awk?
On Thu, Apr 17, 2025 at 08:23:18PM +0200, Simon Josefsson wrote: > Is it possible to drop 'mawk' from the set of default tools in trixie? Regardless of the practical and important questions others raised on why and how to actually do it, no change like this could be done responsibly at this point of the trixie release cycle. We just entered the second part of the freeze (soft freeze) last Tuesday April 15th. Or, did you mean forkie? signature.asc Description: PGP signature
How to remove 19 raku-* packages from all ARM architectures ?
Hi Currently rakudo cannot be shipped on arm architectures because of build issues. Upstream is working in this, but in the meantime, raku is not suitable for ARM. I've required the removal of moarm, nqp and rakudo from unstable/arm*, which was done a few days ago. But I forgot that all raku-modules are Architecture: any, which means that all these module must also be removed from unstable/arm*. There are 19 packages to be removed from arm*. Should I log one bug for all 19 packages, or one bug per package ? All the best
Dropping perl? (Was: Re: Dropping awk?)
On 18/04/25 23:17, Jonathan Dowland wrote: On Thu Apr 17, 2025 at 7:23 PM BST, Simon Josefsson wrote: I noticed that Fedora 42 was released and their docker images lack a 'awk' tool. They likely lack perl, as well. Most/all awk usage in maintainer scripts could probably be replaced with perl. But, if you are in the minimizing game, perhaps you'd rather remove perl from the essential set? A substantially harder project. My hobby for the past three years has been working on removing perl from the transitive essential set. It's very doable. I have PoC VMs where perl is not installed at all. I'm very slowly polishing and upstreaming my changes: I've sent dozens (hundreds?) of patches and there now are only about 40 maintscripts where perl is directly used. Most importantly, I've already removed all uses of perl from postrm maintscripts in bookworm. I've also written shell-only replacements of Perl programs used in the transitive essential set. Once forky is open for development I may send a more public announcement of this project. Regards, -- Gioele Barabucci
Re: POSIX sh compatibility (Re: Dropping awk?)
On Fri, Apr 18, 2025 at 02:52:17PM +0800, Sean Whitton wrote: 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. I think POSIX is mostly a relic, and not worth worrying about except as one of many inputs. Too many mistakes were made too early on, and it's just too late to get everyone to agree on a common standard because real world implementations diverged in too many ways. If someone wants to make a program that works reliably across platforms sh isn't the right tool in 2025. (And I say that as someone who quotes POSIX regularly: it has value for things like choosing amongst a set of possible implementations, but not for making assumptions about what will work in the real world.) GNU m4 doesn't follow POSIX strictly, unfortunately. Very few things do. POSIX itself has been trying harder to reflect reality in areas where nobody wanted to follow the standard, but then you're left with the problem that there's no straightforward way to discover which version of the standard a particular tool is using. See these workarounds for both the potential lack of m4 and the lack of GNU m4 behaving POSIXly: I'm curious what modern platform doesn't have mktemp; is this more than an academic question?
Re: Dropping awk?
On Thu Apr 17, 2025 at 7:23 PM BST, Simon Josefsson wrote: I noticed that Fedora 42 was released and their docker images lack a 'awk' tool. They likely lack perl, as well. Most/all awk usage in maintainer scripts could probably be replaced with perl. But, if you are in the minimizing game, perhaps you'd rather remove perl from the essential set? A substantially harder project. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Bug#1100677: Pending autoremoval of debian-reference* packages
On 2025-04-17 Osamu Aoki wrote: > 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? [deleting drafted response] This has been resolved in the BTS. cu Andreas
Re: Dropping awk?
El 17/4/25 a las 21:03, Colin Watson escribió: 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! Big oops! I wonder how small they want images to be to consider 263 KB unbearable. Thanks.
