From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id eDCnBeV+7GQsOwAAG6o9tA:P1 (envelope-from ) for ; Mon, 28 Aug 2023 13:03:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id eDCnBeV+7GQsOwAAG6o9tA (envelope-from ) for ; Mon, 28 Aug 2023 13:03:01 +0200 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 D83BA311EA for ; Mon, 28 Aug 2023 13:03:00 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-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=1693220580; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=pou9UIlSzxjBf3Q2xcemeNQ/FXnOhij218DJP47NYmI=; b=DH8MmdTwZxRX2EhuikFqUJAqnV46e2G58baZvzMg8tNUH1yevjTRxXeBqKmfgkdpi+PUDb np7dBmG1Sm0GlSwRFltQbY8Vq/AO8+R7QM9vQ7/n87cbidQ0ixLQL+7d5A8VKP/2zPkA/p UY2WC9icHMSqytFZdyJAQtvMkfK/hWk5Pv6DaHXH3rHZaSquYBzoclK0NHBwv/s4kwXR0A 2ZrRo1M4jua6Je3RAPLQpoI4bAzM+gNEqg2ylbFlqTdw4OxxGE3knnHweELpWjHHmU/xQq 8OoRhtWzjhrKqMtmnz8H/We74U2xC27fCFFCvoDQcd4s6VWED02k2Zam9llz4Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693220580; a=rsa-sha256; cv=none; b=ka4pJi4zxm/EDGAzSwMuC7eyHBXvpM1KB+bqHrRPUO+ZqxOyJlQbternemci2o3oNj/iFl gZBZ8q8+R9k5kR32d31pQWAoOSAj48yLei5nHfkBk7puytiPPtad3CacnHqs1uiqhltERQ g1i0adAB9WAJPmpvK3RE6fnU3jnhqWEjyze5vpzK5Ne9JQejYVroKBN2HePHKnHROslHPl vyTedlpBDKUpTkKKPxG+4w0ykDXzml74kfMzpjcThP2M/AjLGna0ERX+gWcnTipuIeItxT gzjkRZJ8R1S8qGwdsR3KdAuE6QwOx37iY4GeIu82WJeEl2PouGw2aK/QYo3H5w== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaa12-0008G4-Fr; Mon, 28 Aug 2023 07:02:40 -0400 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 1qaa0b-00089y-8e; Mon, 28 Aug 2023 07:02:23 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaa0S-0003Sl-Aw; Mon, 28 Aug 2023 07:02:11 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 4D26C1BF20F; Mon, 28 Aug 2023 11:01:53 +0000 (UTC) From: Nicolas Goaziou To: Emmanuel Beffara Cc: help-guix@gnu.org, guix-devel Subject: Re: documentation in TeX Live collections References: <20230825121743.GD1356@beffara.org> <87bkesrdx0.fsf@nicolasgoaziou.fr> <20230828094924.GB1032@beffara.org> Date: Mon, 28 Aug 2023 13:01:53 +0200 In-Reply-To: <20230828094924.GB1032@beffara.org> (Emmanuel Beffara's message of "Mon, 28 Aug 2023 09:49:24 +0200") Message-ID: <871qfnqvku.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: admin@nicolasgoaziou.fr Received-SPF: pass client-ip=217.70.183.201; envelope-from=mail@nicolasgoaziou.fr; helo=relay8-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx2.migadu.com X-Migadu-Spam-Score: -6.32 X-Spam-Score: -6.32 X-Migadu-Queue-Id: D83BA311EA X-TUID: YYKzJmVEDJSJ Hello, Emmanuel Beffara writes: > Yet, as far as I know, most packages in Guix (apart from texlive-* ones) come > with their documentation, so it feels somewhat inconsistent. Every texlive-* package comes with its documentation, in a separate output. "doc" output are not uncommon at all in Guix. Therefore, I disagree with the inconsistency you're talking about. > not including the docs in the main outputs can make sense, especially given > the volume it represents. Anyway, given that there is extensive documentation > in TeX Live, it seems only natural to have it easily accessible. Barring the `texdoc' issue, documentation is easily accessible; you just need to install the "doc" output of the package you're interested in. >> Would the following definition for texlive-texdoc solve both issues >> mentioned above? (the warning and the error.) > [...] >> (add-after 'link-scripts 'wrap-programs >> (lambda _ >> (wrap-program (string-append #$output "/bin/texdoc") >> '("GUIX_TEXMF" = ("${GUIX_TEXMF%:*}")))))))) > > It would certainly remove the warning but it would make only the first path > usable by texdoc, while other tools seem to support having several paths in > GUIX_TEXMF. Besides, I don't understand how GUIX_TEXMF is taken into account > by the various tools. Web2c and co don't know them, so there must be some > wrapping or patching somewhere in the package definitions? It seems some programs do handle it fine, e.g., tlmgr, but not all of them (e.g., texdoc or chktex). In any case, I don't know enough about this part of the code to answer this. > Is there a way to diagnose that kind of thing? I stumbled on a similar > behaviour in other contexts and was unable to investigate it (in my case, big > debug versions of Qt libraries are often downloaded, although I neved > requested any debugging version of anything). Usually, there is `guix graph --path package1 package2', which explains why package2 is installed along with package1. I couldn't get any meaningful result in this case. >> If that's a common request, we could add a `texlive-collection-foo-doc' >> package that would propagate all "doc" outputs from all packages >> included in `texlive-collection-foo'. >> >> However, I'm a bit reluctant to add more artificial packages (i.e., not >> known to TeX Live distribution). Also, it might be as simple to do it in >> one's own manifest. > > I think it would make much more sense to have "doc" outputs also for > collections and schemes. It would be consistent with the structure of > individual packages and would not require artificial packages. I disagree. Collections are meta-packages. There is no documentation, nor content, attached to them. Moreover Guix meta-packages do nothing special about the documentation of packages they propagate. This would be inconsistent. > Having individual package documentations in one's manifests is of course > doable but it is contradictory with the approach of collections. How so? In any case, I suggest to write a proper bug report for this. Hopefully, someone with better understanding about the implications of GUIX_TEXMF will be able to solve this. Regards, -- Nicolas Goaziou