From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 8AMGJD7aNGGNMAEAgWs5BA (envelope-from ) for ; Sun, 05 Sep 2021 16:54:54 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id KPWaHz7aNGHMGgAAbx9fmQ (envelope-from ) for ; Sun, 05 Sep 2021 14:54:54 +0000 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 E7005245A2 for ; Sun, 5 Sep 2021 16:54:53 +0200 (CEST) Received: from localhost ([::1]:42206 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mMtXo-0007mh-VU for larch@yhetil.org; Sun, 05 Sep 2021 10:54:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMtXd-0007kl-1A for guix-devel@gnu.org; Sun, 05 Sep 2021 10:54:41 -0400 Received: from imta-36.everyone.net ([216.200.145.36]:38584 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mMtXa-0001x8-Ow for guix-devel@gnu.org; Sun, 05 Sep 2021 10:54:40 -0400 Received: from pps.filterd (m0004960.ppops.net [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 185Eq5Y2017796; Sun, 5 Sep 2021 07:54:33 -0700 X-Eon-Originating-Account: jsR9hmx-kJyYH3z2AtSdBAdRvSJwMCv7RNDS1NrXjt8 X-Eon-Dm: m0117124.ppops.net Received: by m0117124.mta.everyone.net (EON-AUTHRELAY2 - 5a81dc5e) id m0117124.611f98c0.142ae6; Sun, 5 Sep 2021 07:54:32 -0700 X-Eon-Sig: AQMHrIJhNNooa+XNPQIAAAAE,643dea96f88967357382ee929840c907 X-Eip: AERCo5EdasIWRrHI9cKoK0bkrLjPrfkw5FizqLlNYb4 Date: Sun, 5 Sep 2021 16:54:23 +0200 From: Bengt Richter To: Liliana Marie Prikler Subject: Re: Guix Jargon File (WAS: Rethinking propagated inputs?) Message-ID: <20210905145423.GA3694@LionPure> References: <86h7ezkfq9.fsf@mgsn.dev> <382a46ced17110e1bc03b94ba078b38c2669deac.camel@gmail.com> <20210905095018.GA2963@LionPure> <5492ffcdec13bf81cff285e14d0ff49a78e6c5c9.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5492ffcdec13bf81cff285e14d0ff49a78e6c5c9.camel@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Proofpoint-ORIG-GUID: UcpfHT6f5uyGUQ7p2Q2oLxZXEz0BYUxh X-Proofpoint-GUID: UcpfHT6f5uyGUQ7p2Q2oLxZXEz0BYUxh X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-04_09:2021-09-03, 2021-09-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1034 mlxscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 phishscore=0 malwarescore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2108310000 definitions=main-2109050107 Received-SPF: pass client-ip=216.200.145.36; envelope-from=bokr@oz.net; helo=imta-38.everyone.net X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bengt Richter Cc: guix-devel@gnu.org, Sarah Morgensen Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1630853694; h=from:from:sender:sender:reply-to: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=MbOopyMXo+BXIVspnczK6RnUCFxTHVRHjG4X7jvgTT4=; b=MS3VFsKk3pli4AuCf3OsoSU1whLUQAoEIUmvf75uAOhkfLy5JqJ/nZXG4WSCys0YE5Fj43 NIeL8JN0zUnszH9LPhjokL4K32Xqff4ZsJTH7l4R6L+2I+4bj67RZneV+wT8DDtJPAccAA J2d4OyasgD8fPHR5pVPS7TaAkJenPnGTpFXcoEkEDJgGnevuAsbPL0dp8Nj6kv5KwnZQAL wOJFAU09l/OkpfwFdc/EdPB5mjSIX/FV0vHiaEujTsm7dSN1dA2Sa5sW8MuypiiR+nZzSD hjFb92JIfsexuwebJHQOqep6MtGV/oCBQX/I7oBXVYb7VRB2yAG3n0EZ5fldrw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630853694; a=rsa-sha256; cv=none; b=in1qMlEWZ/eg6POk/tUanw5wwihh88/iV1DhdEEDV0mPtNZomnEGe13HM7A4Zhdj/7b2OZ iGcWhhCuIeau5g/Gljj2erp9mp4TNeaK8Pfe33wGo78yNvZp5aQa91ODUXZU9/hkecRKlM P3lBrVp550pwkMzkFp4CXziHfdxdITMYcEUo4rZb/h6ZZLtr6P6de5gZTW5mHt/RpPEIq/ Ork1JbpPUbJN1/RCZC5OVvjBqQX2l7HgYlOZ20KS4E2GR3p94o7NQPdQ3Cj19bEBmcBBFQ ZpoXECqQOUbAGf/GJ/HuRrE8Q1wDSEPAQueipVVOaMqfLtzggK3mZzQ4BZRIiw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.91 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: E7005245A2 X-Spam-Score: -1.91 X-Migadu-Scanner: scn1.migadu.com X-TUID: VLRTXNcgvuIF Hi Liliana, Thank you for starting this renamed thread (as I should have done). I think a people who are just looking at _maybe_ installing guix should have an easy way to look up terms they haven't seen before. But really I am more interested in promoting the idea of a snippet-quoting convention modeled on a subset of mime email standards. Very simple, but capable of containing and transferring anything unambiguously (if not always with efficient transmission encodings). We can of course already do that with signed and attached files, and we can archive them and retrieve them, but I am interested in retrieving little pieces and making it easy to mark things in arbitratry contexts (like this email or a cannibal-friendly program source) so that simple snarfing utilities will be able to extract snippet-quote info based on tags and identifiers or anything in the headers or content per search options much like for any search engine. This is to create a simple contribution mechanism as well as a format for retrieval. I have seen many code snippets from developers that are tutorial material as well as practical how-tos for debugging and browsing guix. Wouldn't it be nice if they were snip-quoted so that we could extract them from mail archives in a better way than searching the raw archives, or having to browse though treads and extract nuggets by hand? simply: --8<---------------cut here---------------start------------->8--- header part, ending with blank line optional content part, encoded and delimited or referenced per header info --8<---------------cut here---------------end--------------->8--- The header part could start with just prefixing GX- like the optional custom header X- prefix described in mime rfcs, and we could borrow whatever was useful. Tbc.. So called "real life" demands I postpone making a decent real example 'til later, sorry ;/ Please excuse the big top-post. I had intended to comment and edit in line ;/ BTW, I know "info guix|grep -i whatever" often gives clues about whatever, for pursuing "C-s whatever" once inside "info guix whatever", but though concept and api indices are great, they are not a Jargon File, and not as handy for an outsider :) On +2021-09-05 12:50:56 +0200, Liliana Marie Prikler wrote: > Hi, > > Am Sonntag, den 05.09.2021, 11:50 +0200 schrieb Bengt Richter: > > > We don't call things build-inputs here in Guix land, that's a no-no > > > :P > > > > Is there an official guix jargon file or glossary file or texi file > > or wikimedia/wiktionary/wikipedia clone on gnu.org that non- > > cognoscenti could use to get a clue? > AFAIK no, you more or less have to go by what the manual tells you. As > for why we have native-inputs and not build-inputs like other distros, > it's because people often misclassify "build" inputs, so the definition > actually does more harm than good. Guix knows which files are actually > "just used for build" by what ends up in the store, with some > exceptions like UTF-32 encoded strings. > > > Is there a thread that on that topic making any progress on making it > > happen? > AFAIK no. > > > when someone in a thread like this offers a candidate official > > definition, (off-topic sort of, but meta-on-topic for relevant > > documentation) could it be snip-quoted for easy search and > > aggregation for maintainers of official definitions and translations? > > E.g. > > (or actually borrow some rfc0842 or descendant so an attached file > > generates a usuable section in mail archives that can be snarfed > > automatically?) > > > > --8<---------------cut here---------------start------------->8--- > > X-Content-type: Cadidate-guix-jargon-definition > > Ad lib comment and metacomment ended by blank line ... > > "> We don't call things build-inputs here in Guix land, that's a no- > > no :P" > > > > build-propagated-inputs: > > > > --8<---------------cut here---------------end--------------->8--- > When you quote someone like that out-of-context, you run a risk of > misrepresenting what is actually stated. What I mean, is that a > package field called something along the lines of "build-inputs" is > likely to confuse Guix veterans and newcomers alike, as evidenced by > the following reply: > > Am Sonntag, den 05.09.2021, 10:06 +0000 schrieb Attila Lendvai: > > potentially worthless two cents from a newcomer's perspective: > > 'build-time' and 'run-time' are well established concepts in the > > wider community. > And one, that is well misunderstood. > > > if i were reading 'linked-inputs' in a package definition, i wouldn't > > associate it to being the set of build-time dependencies. > That's not what linked-inputs are, though. Take the following > paragraph from propagated-inputs: > > > For example this is necessary when packaging a C/C++ library > > that needs headers of another library to compile, or when a > > pkg-config file refers to another one via its ‘Requires’ > > field. > This use case of propagated inputs explains why they need to be > propagated when given as a (propagated-)input to a package, but not > when given as a native input or merely existing in a profile. > > The – required if we go by other systems – use case of installing > libraries system- or user-wide is already discouraged by Guix, for it > is not needed. As long as we can spawn an environment, in which we can > compile these things, it should be enough. > > Note, that this is not equivalent to being a "build-time" dependency. > Going by Gentoo's definition "Build dependencies are used to specify > any dependencies that are required to unpack, patch, compile, test or > install the package", GCC is a build dependency of nearly any C program > (and a native one at that, i.e. BDEPEND in Gentoo), but it's not a > linked-dependency, because there are numerous ways in which other > programs could use it without ever needing to invoke GCC. Guix, of > course, includes GCC as an implicit native input anyway, but that's a > different topic. > > Regards > -- Regards, Bengt Richter