From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: from mandoc.bsd.lv (bsd.lv [66.111.2.12]) by inbox.vuxu.org (Postfix) with ESMTP id 92826227B0 for ; Tue, 28 Jan 2025 11:40:36 +0100 (CET) Received: from fantadrom.bsd.lv (localhost [127.0.0.1]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 937a6b94 for ; Tue, 28 Jan 2025 10:40:35 +0000 (UTC) Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 7389c0c0 for ; Tue, 28 Jan 2025 10:40:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=usta.de; s=kit1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UvVJLbCdbJaOpTk+3Q8/Lz6g4OEwJZdXW3HpzumY6o8=; b=BDM7ddCI92joHGB4qBjcIct6YY u/xGRAZKj+n7hf8jUCQOCnnsJMUapPjOYa67XpXYFqdP4bvHSUcUMvcLdeXedjD9bP/gyelQWNIsA 5wdgAUb2p3GhVkIh92/YpOGgjpIk23e4tT9tY3k2/BsLGLwxNMRX+wIa0iJ7196bvrd3eLV00hz4R DqbLuCcAgaEsPlVTddjlCdaKCPNP4fu1bXOGUJ8bZU566ysbp68iSs1q679gkAMExNYcbpl3Y2BRG pAtwGEznp1v+TRDMlO3Z+MC7SWj3QJGm5zlj0xvy6ge32VFocfDvrUah+gyqgjsT36q5zeV8PVF9k FKK/F9tw==; Received: by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (envelope-from ) id 1tcj1F-005vlL-1W; Tue, 28 Jan 2025 11:40:33 +0100 Received: from login-1.asta.kit.edu ([2a00:1398:5:f400::72]) by hekate.asta.kit.edu with esmtp (Exim 4.94.2) (envelope-from ) id 1tcj1E-008yHF-FF; Tue, 28 Jan 2025 11:40:32 +0100 Received: from schwarze by login-1.asta.kit.edu with local (Exim 4.94.2) (envelope-from ) id 1tcj1E-005Bwo-05; Tue, 28 Jan 2025 11:40:32 +0100 Date: Tue, 28 Jan 2025 11:40:31 +0100 From: Ingo Schwarze To: Soeren Tempel Cc: discuss@mandoc.bsd.lv Subject: Re: zstd compression Message-ID: References: <3T0GC5KH2QOJE.3MWZ01GDN6VSI@8pit.net> X-Mailinglist: mandoc-discuss Reply-To: discuss@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3T0GC5KH2QOJE.3MWZ01GDN6VSI@8pit.net> Hi Soeren, Soeren Tempel wrote on Tue, Jan 28, 2025 at 08:10:53AM +0100: > Compression schemes beyond gzip are currently being adopted by Linux > distributions for man page compression. Case in point: Guix [1] Yikes. The goal at the very foundation of that software looks misguided in the first place. The purpose of privileged accounts is to make sure that users cannot change the configuration of the machine. Installing software is a typical example where using a priviledged account makes sense and is often even required because it often involves creating daemon accounts or groups or directories owned by specific users or groups or setting up jobs to run periodically. Also, it's good when system administrators have an idea what people are running on a machine in order to keep it properly secured, which also means that it's better when installation is done by the admin. Yes, i know users can always install their own software in their home directory. While trying to prevent that with technical means is usually stupid because it doesn't work very well, people should be discouraged from installing software they need themselves rather than encouraged. On a single-user machine, installing software with your normal user account would be so stupid that it would leave me speechless. So, what is the point? Also, which system uses Guix? I mean, a package manager normally needs to be tightly integrated with the operating system, a stand- alone package manager is an oxymoron (yes, i know the NetBSD thingy, pksrc, wants to do precisely that, but that's mostly useful for exotic systems coming with no packagge manager whatsoever, like AIX). Are there any sane distros switching to zstd? > has switched to zstd compression recently, which has sadly rendered the > Guix mandoc package defunct [2]. > > For other downstream packagers impacted by this, I wanted to point out > that the zstd project provides a wrapper library which is API-compatible > with zlib and easily allows adapting software using zlib (e.g. mandoc) > to zstd compression. A sample patchset for doing that is available in > the Guix patch tracker [3]. > > Given mandoc's stance on man page compression [4], this is rather > intended as an FYI for downstream packagers, but in case there is > interested in proper upstream support for additional compression > algorithm, feel free to let me know. I feel serious tempted to rip out compression support altogether. It's just so anachronistic. By the way, your comment in the thread "Usually, its hard to convince them to add features that do not benefit OpenBSD." is misleading. I have implemented many features that do not benefit OpenBSD in any way whatsoever, and some of these are even availabke is the OpenBSD base system and not only in mandoc portable: * Style checks for manual pages specific to NetBSD. * The mdoc(7) .Lb macro, extensively used by FreeBSD and some others. * Very careful support for manual sections that are not pure numbers but have alphabetic suffixes, mostly for Illumos and Solaris, but also used by some Linux distributions. * ... Some features are only in portable, not in OpenBSD: * Support for "make install" installing symlinks rather than hardlinks. * The READ_ALLOWED_PATH feature for Homwbrew and MacOSX * Support for installing libmandoc.a, mostly for NetBSD * A complete program, mandocd(8), mostly for Debian * and lots of other stuff, most of it visible in configure.local.example But if somebody wants a feature and cannot explain what the benefit is, i do not want such a feature to complicate the code. Then again, in this case, it might not complicate the code at all, in which case i might be willing to accomodate even a foolish feature. That said, let's see what cam be done for your case. It appears you need four elements: * Five new *.o files. I definitely do not want to add the source code for these five files to the mandoc repo. Can you instead install a system-wide shared object containing that code, such that mandoc can dynamically link, just like it is dynamically linking zlib right now? * The argument -lzstd on the ld(1) command line. That should be easy with an option in configure.local.example. * #include in read.c. Can easily be controlled with the same option. * Recognizing the .zst file extension. Can easily be controlled with the same option. By the way, is explicitly linking to both shared objects really necessary? Why does the libzstd_zlibwrapper.so (or however it is called) not know that it depends on libz.so and let ld.so do the work? Not sure whether that's possible, if not, "-lz -lzstd" is not out of the question, either. Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv