From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id ElDvHyNsRGE12AAAgWs5BA (envelope-from ) for ; Fri, 17 Sep 2021 12:21:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id eDj4GiNsRGESJgAAbx9fmQ (envelope-from ) for ; Fri, 17 Sep 2021 10:21:23 +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 7DC19C874 for ; Fri, 17 Sep 2021 12:21:22 +0200 (CEST) Received: from localhost ([::1]:33218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRAzh-0005N6-38 for larch@yhetil.org; Fri, 17 Sep 2021 06:21:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRAzO-0005JK-8C for guix-patches@gnu.org; Fri, 17 Sep 2021 06:21:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:47031) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mRAzN-0006zu-W6 for guix-patches@gnu.org; Fri, 17 Sep 2021 06:21:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mRAzN-0004nE-ND for guix-patches@gnu.org; Fri, 17 Sep 2021 06:21:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#50627] [PATCH 0/2] Make wayland-protocols dependency native-input. Resent-From: muradm Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 17 Sep 2021 10:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50627 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Liliana Marie Prikler Cc: 50627@debbugs.gnu.org Received: via spool by 50627-submit@debbugs.gnu.org id=B50627.163187401318357 (code B ref 50627); Fri, 17 Sep 2021 10:21:01 +0000 Received: (at 50627) by debbugs.gnu.org; 17 Sep 2021 10:20:13 +0000 Received: from localhost ([127.0.0.1]:58577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRAya-0004m1-NV for submit@debbugs.gnu.org; Fri, 17 Sep 2021 06:20:13 -0400 Received: from nomad-cl1.staging.muradm.net ([139.162.159.157]:58090 helo=nomad-cl1.muradm.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRAyY-0004lo-Cm for 50627@debbugs.gnu.org; Fri, 17 Sep 2021 06:20:11 -0400 Received: from [176.234.10.27] (port=7008 helo=localhost) by nomad-cl1.muradm.net with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mRAyY-0000dB-4L; Fri, 17 Sep 2021 10:20:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=muradm.net; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: In-reply-to:Date:Subject:Cc:To:From:References:Sender:Reply-To: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=XgQAmSAN78EeE6Pnny7k3vBRgqcoppImUTjHAa4fdU4=; b=HfX9ZSJr4Hx2yDewp8ueoIV5+4 dG5IFKtpvViGN27M0h4jpYnRISo2BQsXQPa7HEpgF2pAp4xRuq2hedkpO7N9XmTFOh22bC7+OGMel Q2QYlx5RLVki7GTDIsrojI5JonSP2RdMZX8Hj3+uEAcrCsVjo6tE9nPAsH23jLwScR03f5WK4uRip k7QUDRIIOi6VZVBSzSF3w+PQdKodIBQPrAnS7qk/rnVEpMIx+V4DZCkunOKUM158JHHtwy0fn8WyP gAT51awEja30xexivmP5gMdPz7byrPrT7sPV515VJZtLWnd4X/Oyc5dX2v4Q9AKr0xHLddZFlLVP4 fLKf4MlU6VYNP8Cyl+853+hg0KhQwho3N03dyYVgZrwTLSIDWAH9BcrQc6ThKMXp0s6FFDcXvdUm4 O1X8ILSvyupah8aMp2AqrNCV9E2y+VQNofYvwrDLGTRNVDN4rEpNc0dBy/yx7v5So5tnwkzTTC/2U hqc28pQwWs4CZ+LSEX+7t5Y1; Received: from muradm by localhost with local (Exim 4.94.2) (envelope-from ) id 1mRAyV-0002ze-5s; Fri, 17 Sep 2021 13:20:07 +0300 References: <20210916192331.29606-1-mail@muradm.net> <87ilyzg96v.fsf@muradm.net> <4bb63f130f3ec7dac628a8139c405cdc202412e9.camel@gmail.com> User-agent: mu4e 1.6.5; emacs 28.0.50 From: muradm Date: Fri, 17 Sep 2021 11:20:10 +0300 In-reply-to: <4bb63f130f3ec7dac628a8139c405cdc202412e9.camel@gmail.com> Message-ID: <875yuzfqqw.fsf@muradm.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1631874082; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=XgQAmSAN78EeE6Pnny7k3vBRgqcoppImUTjHAa4fdU4=; b=eEB3jH0OMp7LuFkAu6SbfZZCuCiFxFDRI++j18OmBff83s81XFXgwH/kiD+4zGng/sP2MZ dIPpG4TlrBB7FgNgcNmbnivarmcr3rQihZTK2Ejp5wejM54QGSYRnCSWgpjfTWnlHyWKge XxX693NZP1c5R48LB6u+BozRNMN/N3Gu6ljPEijEeG01kqw1KqZ1LzGx0wKqgaB1HEQo9M MKtTS7ZDObqfvoA2jvrnkootmEP1UUsJHEfAaV6TAEEEV0yVBGKh4Ro8MUHCf8dLf8fJik 42HR2Ryfweznlm3WYeMQhSHHKHLCncwVi3r4xLFUh5INYtgcLtAgym6qzK+PLw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1631874082; a=rsa-sha256; cv=none; b=qMzJQNdzJFSHl7ljs5LS1NZwUONF5k7z+L9Hu9pX7ZVRnPZukZN24ri7sJ6yG0CeSngROT WN1kYR4EZgnQXpvHOyk+m8ZpfjWzeivR52wLWzbpi+HxBeIsZdz+rCqU81db9XkShC5ESn RCwlrDoC8voinTojRP2M3vydYs+0Dc5onVHAhe1SN8KJ9XbhdycIeUNobTT9yoJ1KxTiaE QT0CBVRvHY/7kvDjQxQOHtEnVRG15q228wcifkTRuxeO29CCZxlYkvUr+k9Z+7FuPzMG6J KY2Ou9cl6wQDHmwSge1038+Bke08N9nZt0ODXtz0v0v8KEFO3e58NLxk6QeDUQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=muradm.net header.s=mail header.b=HfX9ZSJr; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.39 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=muradm.net header.s=mail header.b=HfX9ZSJr; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 7DC19C874 X-Spam-Score: -1.39 X-Migadu-Scanner: scn0.migadu.com X-TUID: u9RXxyOZiEcZ Regardless of comments below, I understand what you are trying to=20 point out. It is fine with me to use 'inputs instead of 'native-inputs,=20 as the final result won't change. Just in my opinion, what I found it=20 that, it need/should not be in 'propagated-inputs. I will be updating the=20 patch to make sure that wayland-protocols are listed among 'inputs=20 without propagating. It is also fine with me to close this issue and don't=20 do anything if you say that it is unnecessary, I don't mind :) Liliana Marie Prikler writes: > Hi > > Am Freitag, den 17.09.2021, 05:35 +0300 schrieb muradm: >> Liliana Marie Prikler writes: >> >> > Hi, >> > >> > Am Donnerstag, den 16.09.2021, 22:23 +0300 schrieb muradm: >> > > wayland-protocols is not runtime dependency and only build=20 >> > > time >> > > dependency for applications that directly using wayland. >> > Guix does not distinguish between "build time" and run time >> > dependencies. >> True, here issue could be related to miss wording, but same >> wording is used in the manual as well, so do I. > I'll respond to that in your quote below. > >> > > Initially I tought that making wayland-protocols a >> > > native-inputs dependency as it should, it would reduce=20 >> > > number of >> > > dependants on it. But it turns out other way around. With=20 >> > > this >> > > patchset we are fixing gtk+ to not advertise it as=20 >> > > dependency in >> > > its .pc files, and moving wayland-protocols to=20 >> > > native-inputs >> > > where it should be. >> > That's not what native-inputs are used for. native-inputs >> > provide binaries that the host/build machine needs to run in=20 >> > order >> > to compile a package. It doesn't seem to be the case that=20 >> > wayland- >> > protocols is such a package, is it? >> wayland-protocols is different package. It does not include any >> binaries only protocol specifications (some xml files), which=20 >> are >> used for code generation. We could consider them as a kind of >> autoconf/bison like inputs, but tightly scoped for wayland=20 >> needs, >> although they are not so and not binaries. > And what kind of code is generated from them? I would assume=20 > it's > target code. And since wayland-protocols is no tool to process=20 > those > XML files, but the files themselves, I'd hazard a guess that it=20 > should > rather be built for the target. While currently this appears to=20 > make > no difference, there might well be a time in which those files=20 > differ > for some two architectures, which then would cause problems in=20 > cross- > compiling contexts were it a native input. As with any other kind of protocol, you can implement platform=20 specific encoder/decoder, but protocol remains the same. Suppose,=20 connecting from arm, to x86 or vice versa in the context of wayland, should=20 protocol change? As you mentioned wayland-scanner below, that would be its=20 task to interpret protocol specification in platform specific way. So I=20 would speculate that in future these specifications would remain the=20 same. Otherwise, that would defeat the point of having protocol. >> > > Patch provided for gtk+ also merged with upstream. >> > > >> > > Patchset prepared from core-updates-frozen. While it seems=20 >> > > that >> > > it will impact many other packages, actually this patch=20 >> > > reduces >> > > number of packages that touches wayland-protocols and=20 >> > > probably >> > > avoids it at runtime. >> > But it still impacts a large number of packages in ways that >> > could >> > potentially break and haven't been tested, right? >> Technically, this package does not change anything in terms of >> binary producing. wayland-protocols remains to be an input as=20 >> it was >> before. I.e. wayland compositor, wayland application, wayland=20 >> using >> library, application which uses wayland using library, binary=20 >> output >> is not impacted. If binary output is the same, is there any=20 >> thing >> else to test? > In that case I'd hazard a guess that it's fine, but the phrase > "wayland-protocols remains to be an input" is perhaps a bit=20 > weird given > the change to native-input. Probably, I'd better put single quote in front of the word when it means symbol, and don't put one when it is human word :) in this=20 context it was meaning literal input (regardless of type, be it 'inputs, 'native-inputs or 'propagated-inputs). >> There are two things which are being changed. First as you >> pointing out is the way Guix treats it, i.e. reducing closure,=20 >> etc. >> Second is propagation of inputs. Currently (without this=20 >> patch), >> since it is listed in propagated-inputs (and also advertised in=20 >> .pc >> files), wayland-protocols as requirement, needlessly, getting=20 >> pushed >> down then hierarchy. > We ought to move it from propagated-inputs to inputs and either=20 > (if we > can) ignore pkg-config or patch the pkg-config files. W.r.t.=20 > pkg- > config I do wonder whether Requires.private needs propagation,=20 > though, > it normally should be just Requires. I suppose, it is not in Guix's hands to control how pkg-config=20 files are authored by software owners and/or interpreted by build tools.=20 What Guix's can do, it to fix what is already there. This patch=20 illustrates this point. >> Let's take 4 cases that we have here (I do not pretend to be >> complete, of course, there are might be more=20 >> levels/combinations, >> just attempting to illustrate current case in simple=20 >> words/terms): >> >> 1. wayland compositor (weston, wlroots/sway, etc.) >> 2. wayland client application (grim, mpv, etc. applications >> directly interacting with wayland interfaces) >> 3. wayland client library (qt or gtk+ in this case, also=20 >> directly >> interacts with wayland to abstract it for user applications) >> 4. user application of wayland client library (in this case=20 >> some >> gtk+ based application) >> >> For 1 and 2, both types should have to specify wayland in=20 >> inputs >> (or propagated-inputs), and wayland-protocols in native-inputs. > Why? One implements the protocol, the other uses it. I.e. both need=20 stubs generated from specification to agree. Which is not the case for anything beyond 4. Otherwise, we would defeat whole point of introducing abstractions. >> One of purposes to have layer 3, is to abstract from 1 and 2. >> i.e. when I write gtk application, as user I should not be=20 >> aware >> of where/how this application is going to run, via xorg or=20 >> wayland. >> Then why I should be aware of wayland/wayland-protocols and=20 >> make >> sure that it is provided as build input for my application? > IIUC you don't need to be aware when gtk propagates the input?=20 > It's > similar to how you still need an Xorg server to test your GTK > application. >From application using gtk stand point, it does not matter what is behind gtk. As you point out, of course me, as user launching application, I have to provide some environment which could be either xorg or wayland. But application's source should not be aware of that fact. >> More over, if I will have some other unrelated package that >> depends on my gtk application (item 4 above), i still will see >> wayland-protocols among my inputs. >> >> Currently, thanks to Guix, it is getting resolved by having it >> listed in propagated-inputs. >> >> For the long run, it was also fixed in gtk, so that >> wayland-protocols is not going to be advertised in gtk's .pc=20 >> files >> any more=20 >> (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3960 >> and https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3961). > Which is fine in and of its own, but not the right thing w.r.t.=20 > native- > inputs. > >> I suppose that, initially wayland-protocols was listed in >> propagated-inputs for this same reason, because gtk was >> advertising it in .pc files. > Probably. > >> > While reducing closure size is generally a good thing, I=20 >> > think we >> > do need to be careful whenever "build time vs. run time" and=20 >> > native >> > vs. non-native are confused. >> I'm using terminology as per documentation :) may be it should=20 >> be >> reworded in some other way to avoid confusion. 8.2.1 package >> reference: >> >> =E2=80=98native-inputs=E2=80=99 is typically used to list tool= s=20 >> needed >> at build time, but not at run time... > You're quoting the manual out-of-context and (accidentally)=20 > misuse the > word tool. > >> When cross-compiling, dependencies listed in =E2=80=98inputs= =E2=80=99=20 >> are >> built for the _target_ architecture; conversely, >> dependencies listed in =E2=80=98native-inputs=E2=80=99 are bui= lt for=20 >> the >> architecture of the _build_ machine. > This is the distinction to make here. "Typically used to list=20 > tools" > here means that the package provides a tool (i.e. a binary) that=20 > you > invoke at some point of your recipe. This can be a compiler=20 > like GCC, > a tool to create Makefiles like automake, or an X server to=20 > launch > tests in. The only thing in that regard when talking about=20 > wayland > would be the wayland-scanner tool provided by the wayland=20 > package. > > Notice the contrast to what you said before with wayland being=20 > an input > and wayland-protocols being a native one. If you need=20 > wayland-scanner > for you build, it should be a native-input (as well as an input, > probably). If this does become a problem later on, a bin/lib=20 > split for > wayland might make sense. I understand what you are saying, however as far as I am aware,=20 people being or not on the same page, tend to use simpler definitions for referencing something. I was assuming that in this mailing list we are on the same page, and free to choose to how reference things. I suppose it would be fine to say "not runtime dependency", "build=20 time" or "dependency for host platform when crosscompiling" in reference=20 to 'native-inputs. For instance when explaining this to one who sees=20 Guix for the first time, I would say "run time" for 'inputs and "build=20 time" for 'native-inputs, not mentioning "crosscompiling" at all on day=20 one. Any way, I beleive it is more like phylosophical subject, than=20 technical. > Regards