From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 6GHeCaykvmMahAAAbAwnHQ (envelope-from ) for ; Wed, 11 Jan 2023 12:59:40 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id SBSVCaykvmN/DgEAauVa8A (envelope-from ) for ; Wed, 11 Jan 2023 12:59:40 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F341915F90 for ; Wed, 11 Jan 2023 12:59:39 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pFZl8-00056D-Qv; Wed, 11 Jan 2023 06:59:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pFZkz-00055s-D7 for guix-devel@gnu.org; Wed, 11 Jan 2023 06:59:02 -0500 Received: from smtpmciv2.myservices.hosting ([185.26.107.238]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pFZkx-0002dm-1q; Wed, 11 Jan 2023 06:59:00 -0500 Received: from mail1.netim.hosting (unknown [185.26.106.172]) by smtpmciv2.myservices.hosting (Postfix) with ESMTP id 4EEAF20CCE; Wed, 11 Jan 2023 12:58:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail1.netim.hosting (Postfix) with ESMTP id EAD748009C; Wed, 11 Jan 2023 12:58:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail1.netim.hosting Received: from mail1.netim.hosting ([127.0.0.1]) by localhost (mail1-1.netim.hosting [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KipPzitddRg0; Wed, 11 Jan 2023 12:58:37 +0100 (CET) Received: from [192.168.1.239] (unknown [10.192.1.83]) (Authenticated sender: lumen@makinata.eu) by mail1.netim.hosting (Postfix) with ESMTPSA id 552FD80099; Wed, 11 Jan 2023 12:58:37 +0100 (CET) Message-ID: <0cbc38f9-6b50-9653-7a67-4e0b16ca3e06@makinata.eu> Date: Wed, 11 Jan 2023 11:58:36 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: Improving how NGINX modules are used and built Content-Language: en-US To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: guix-devel References: <87pmborneu.fsf@gnu.org> From: Bruno Victal In-Reply-To: <87pmborneu.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=185.26.107.238; envelope-from=mirai@makinata.eu; helo=smtpmciv2.myservices.hosting X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673438380; a=rsa-sha256; cv=none; b=HLbVge7presH7EMxzeGiqWHjmjKyGLGef2ow7Iw0LfckrkA99td8JT0NsSZNS2sFiRvCL+ jQMRt2qrFtFbPnML9BFfVtmadzWdk1LwHda0sLFVmr2wRT80/twvvRdleyKt+N7Xo42zCC 1Y9P9RWrNvWXaBe6J5ZmxEXd/THIqtUFi/rfhiEMelG9VOHV+Uuc61sncvJ74SvApr4gzC Wv0mZ1iCTW/Xt5ZWpWZJa4XEn1GxMMHdzaCtTOImYgryIbfSte2lm+Jg6S16esGo5D2fM6 piNe0+Cn8Jq8A2GTcyZo7uR4NQqr0drN+XFNnr0fICSnBYquK3UqKHEK4Tr6+Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673438380; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=fVlhU3CT5fHyJe2CdGVvdpYlupY10QC4dEhuWg3wCZ0=; b=cMr7BVKY7YLmILzcWBYABWvQ6Vc8/yiFqy0lPCoc26+C6zRg26MF9iMY/DUWZyALTxdnl7 yno5fJ1Xzkwij7KT8EXkzX46V23Z8XYBTrUmZnDPsvK8I83MLqa7rgKHoHSZhhXWogYnRD az2IhVxoKKgDwGd8y+TCoYvjxuV5pp45E0WQIYtwpr/No2+tAc53xvun0J4dm2eWy+oEPl jUye/Fuqhdn3KAd50zi6LM/hfv/asPIV+i0Rq1w7B3kmcuoFLDAsEb1l6EXzkH/aooupYj 1NPbV6Xa663+d48kE0uMrzsgd8ocZedj9rQf+eFbuDXQ+ieyqec1R88gRWtBTw== X-Migadu-Spam-Score: -1.39 X-Spam-Score: -1.39 X-Migadu-Queue-Id: F341915F90 X-Migadu-Scanner: scn1.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none X-TUID: QtvzZeurL1i8 On 2023-01-09 10:51, Ludovic Courtès wrote: > Hello! > > mirai skribis: > >> An oddity of how nginx modules are packaged in guix is that they all place >> the .so file under /etc/nginx/modules which is an odd directory to place library object files. > > To me that should be treated as a bug. Those .so files should go to > $PKG/lib/nginx instead, or something similar. Fixing this bug is likely to cause pain to existing module users, as the path to these .so files is explicitly passed to and is what's documented in the Guix manual. <... continued below ...> >> Looking at how network-manager-configuration handles its vpn-plugins field, it seems doable >> that a similar approach can be used here. >> The existing nginx-modules should be changed to install their .so files under lib{64}/nginx >> instead and they should drop a etc/nginx/modules/foo_module.conf file responsible for loading >> the module from the .so file. Including modules through a .conf should be preferred as >> there's no guarantee that a module is a .so file or that it is always a >> _single_ .so file but in general this file should typically be a one-line .conf file containing: >> >> load_module "/gnu/store/......nginx-foo-module/usr/lib64/nginx/ngx_foo_module.so"; >> >> >> And nginx-configuration should serialize the modules field as a series of lines including >> the module .conf files, that is: >> >> include "/gnu/store/......nginx-foo-module/etc/nginx/modules/ngx_foo_module.conf"; >> include "/gnu/store/......nginx-bar-module/etc/nginx/modules/ngx_bar_module.conf"; >> ... >> >> (note: a directory union could be used here as an alternative) > > I’d say that ideally, one could extend with > modules, and that would automatically create the ‘load_module’ > statements. A change here would really improve how modules are used (the current way of things in Guix is: for beginners: "guess the module path", for the seasoned: "build and list the package output directory"). Inevitably, this won't be a backward compatible change unless we yet add another deprecation warning and a new field "temporarily" (read as: permanently). (or maybe using match to differentiate between strings and file-like objects?) I'm not convinced that should be generating load_module statements here, these should be generated by the module-package itself into a .conf file and generates a include statement for it. Reason being that nothing stops a module being comprised of several .so files or be a "pseudo-module", that is, it's a .conf snippet to be included. I haven't encountered modules like these yet but there's nothing saying that they can't be done this way. Cheers, Bruno