From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 17 11:20:47 2021 Received: (at 50627) by debbugs.gnu.org; 17 Sep 2021 15:20:47 +0000 Received: from localhost ([127.0.0.1]:60925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRFfS-0002Xd-QW for submit@debbugs.gnu.org; Fri, 17 Sep 2021 11:20:47 -0400 Received: from nomad-cl1.staging.muradm.net ([139.162.159.157]:58094 helo=nomad-cl1.muradm.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRFfN-0002XQ-5v for 50627@debbugs.gnu.org; Fri, 17 Sep 2021 11:20:45 -0400 Received: from [176.234.10.27] (port=7646 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 1mRFfN-0000hF-0n; Fri, 17 Sep 2021 15:20:41 +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=0RowzlpPO1TKL6bY8klhjzNaDaalNeuiXeKFr4IxysM=; b=NK1DkMvcXMQYUyzTBF70iKh1tt RMuN03xorlCwJC7AOm99I3X/ffjd/FTwu9V3n+Gy2RtyFfYuI0vp1UUuHbFbfgDUZKoCvCsRCz+xd NaGKqxzczEqQQvs1MiYZnjh3s0HUA2IFvz55lYLfMtjEcEYKTWEROzlmKTySLGCZRGlBc5PbmSkq2 hiuSayeVWQ5qL/g2PaJ8R0pjq28K7WXdWRY3oeR2DBsTwJHoa901s9tnRPVGVGTbljQzTW4wip0aR 7nVBo+qlAj7RSpQs4VjhRjxqLIxzosalbBT2rhe2rtUgcXAQ7B6ihWaAFMdw02I1XBcFRWSZ934tY bo+BgpIT2+lB1A7un+J0Q0GqHGDRJKnK07rty2vVdWAP+U4KjxLi7mTZxcbBxTiOl2Hb2nnKQt0Rf cD31RSkjVx+EnZEwe/fFnVWMfVOkr8Hz/D1nTj/PxvECLtx9aiL472SIZKPDpF2X/7cde3JKndoqD vk6ooUPHn2xNtI6MtymZ3jop; Received: from muradm by localhost with local (Exim 4.94.2) (envelope-from ) id 1mRFfJ-0000MC-Uy; Fri, 17 Sep 2021 18:20:37 +0300 References: <20210916192331.29606-1-mail@muradm.net> <87ilyzg96v.fsf@muradm.net> <4bb63f130f3ec7dac628a8139c405cdc202412e9.camel@gmail.com> <875yuzfqqw.fsf@muradm.net> <830e045c54e06b0b0beaee30837f575a25cec986.camel@gmail.com> User-agent: mu4e 1.6.5; emacs 28.0.50 From: muradm To: Liliana Marie Prikler Subject: Re: [PATCH 0/2] Make wayland-protocols dependency native-input. Date: Fri, 17 Sep 2021 17:11:52 +0300 In-reply-to: <830e045c54e06b0b0beaee30837f575a25cec986.camel@gmail.com> Message-ID: <87bl4rdy9m.fsf@muradm.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 50627 Cc: 50627@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Apart of comments, I updated the patch, in the way that for now it only touches gtk+ package. There are two suspect packages remain who propagate, is wlroots, and enlightenment. enlightenment is=20 most likely to remain leaf package, wlroots is different, we may look=20 at it later when updating it. Thanks in advance, muradm Liliana Marie Prikler writes: > Hi, > > Am Freitag, den 17.09.2021, 11:20 +0300 schrieb muradm: >> Regardless of comments below, I understand what you are trying=20 >> to >> point out. It is fine with me to use 'inputs instead of=20 >> 'native- >> inputs, as the final result won't change. Just in my opinion,=20 >> what I >> found it that, it need/should not be in 'propagated-inputs. I=20 >> will be >> updating the patch to make sure that wayland-protocols are=20 >> listed >> among 'inputs without propagating. It is also fine with me to=20 >> close >> this issue and don't do anything if you say that it is=20 >> unnecessary, I >> don't mind :) > I agree that reducing propagated-inputs is a good thing, it=20 > should just > be moved to inputs. When you update the patch, please do use=20 > the > upstream version of gtk3-wayland-protocols-dependency.patch. I suppose it is impossible, upstream patches are for source in=20 git, gtk+ package is being built from post-processed source tarball. When=20 patching upstream target is configure.ac and meson.build, when patching=20 source tarball, configure script it self. [...] >> As with any other kind of protocol, you can implement platform >> specific encoder/decoder, but protocol remains the same.=20 >> Suppose, >> connecting from arm, to x86 or vice versa in the context of=20 >> wayland, >> should protocol change? As you mentioned wayland-scanner below,=20 >> that >> would be its task to interpret protocol specification in=20 >> platform >> specific way. So I would speculate that in future these >> specifications would remain the same. >> Otherwise, that would defeat the point of having protocol. > You are probably correct in that those files will likely stay=20 > the same > for all platforms, but there could be scenarios where for the=20 > sake of > performance or whatever else you might want to have some=20 > protocol > extensions. Platforms that don't support those then wouldn't=20 > ship said > protocol extensions. Btw, gtk+'s native-inputs are interesting tho.. :) [...] >> > > There are two things which are being changed. First as you >> > > pointing out is the way Guix treats it, i.e. reducing=20 >> > > closure, >> > > etc. Second is propagation of inputs. Currently (without=20 >> > > this >> > > patch), since it is listed in propagated-inputs (and also >> > > advertised in .pc files), wayland-protocols as requirement, >> > > needlessly, getting pushed down then hierarchy. >> > We ought to move it from propagated-inputs to inputs and=20 >> > either >> > (if we can) ignore pkg-config or patch the pkg-config >> > files. W.r.t. pkg-config I do wonder whether=20 >> > Requires.private >> > needs propagation, though, it normally should be just=20 >> > Requires. >> I suppose, it is not in Guix's hands to control how pkg-config >> files are authored by software owners and/or interpreted by=20 >> build >> tools. >> What Guix's can do, it to fix what is already there. This patch >> illustrates this point. > The point of authoring is a weird one when Guix can absolutely=20 > still > patch the file *and* you supplied a patch that was accepted=20 > upstream. > A patch, which mind you is arguably more correct than the one=20 > you've > supplied for Guix, patching the build files themselves rather=20 > than > generated sources. > > For other packages with similar issues without an upstream fix,=20 > you > could on the other hand simply substitute* the .pc file. Please, see reason mentioned above, on why patch is different. >> > > Let's take 4 cases that we have here (I do not pretend to=20 >> > > be >> > > complete, of course, there are might be more=20 >> > > levels/combinations, >> > > just attempting to illustrate current case in >> > > simple 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 >> > > directly >> > > interacts with wayland to abstract it for user=20 >> > > applications) >> > > 4. user application of wayland client library (in this case >> > > some >> > > gtk+ based application) >> > > >> > > For 1 and 2, both types should have to specify wayland in >> > > inputs (or propagated-inputs), and wayland-protocols in=20 >> > > native- >> > > inputs. >> > Why? >> One implements the protocol, the other uses it. I.e. both need >> stubs generated from specification to agree. Which is not the=20 >> case >> for anything beyond 4. Otherwise, we would defeat whole point=20 >> of >> introducing abstractions. > This still doesn't explain the *native*-inputs assertion. As you point out below: "... the package is invoked at build time (native-inputs) ...", in cases 1, 2 and 3 above, wayland-protocols package is needed once, when 1, 2 or 3 target is being built. No=20 other time wayland-protocols package is needed. This is the reason why I decided initially to keep it in (native-inputs), because=20 definition of (native-inputs) as you explaining in this conversation and as explained in Guix manual, best matches with nature of wayland-protocols, at least in my understanding :) >> > > One of purposes to have layer 3, is to abstract from 1 and=20 >> > > 2. >> > > i.e. when I write gtk application, as user I should not be >> > > aware of where/how this application is going to run, via=20 >> > > xorg or >> > > wayland. Then why I should be aware of=20 >> > > wayland/wayland-protocols >> > > and make sure that it is provided as build input for my >> > > application? >> > IIUC you don't need to be aware when gtk propagates the=20 >> > input? >> > It's similar to how you still need an Xorg server to test=20 >> > your GTK >> > application. >> From application using gtk stand point, it does not matter what=20 >> 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. > This and that are different matters. Application source code=20 > continues > to be blissfully unaware of the fact, but the toolchains to=20 > build your > application are not. Think of it like this: When you use=20 > pkg-config > (or older -config binaries), they spit out a number of compiler=20 > and > linker flags to supply to gcc or ld. You as the application=20 > programmer > are typically unaware of those flags and their values,=20 > especially if > you turn down the verbosity of your build system, but that=20 > doesn't mean > they're not supplied. I don't know about typical programmer, for me as programmer, when=20 I write, I do look at every dependency and how it is included. This=20 case just make uncomfortable when there is dependency which is required but unused. [...] >> I understand what you are saying, however as far as I am aware, >> people being or not on the same page, tend to use simpler=20 >> definitions >> for referencing something. I was assuming that in this mailing=20 >> list >> we are on the same page, and free to choose to how reference=20 >> things. >> I suppose it would be fine to say "not runtime dependency",=20 >> "build >> time" or "dependency for host platform when crosscompiling" in >> reference to 'native-inputs. For instance when explaining this=20 >> to one >> who sees Guix for the first time, I would say "run time" for=20 >> 'inputs >> and "build time" for 'native-inputs, not mentioning=20 >> "crosscompiling" >> at all on day one. >> Any way, I believe it is more like philosophical subject, than >> technical. > I think it is important to acknowledge that people come from=20 > different > backgrounds, and knowing that to do our best to curb=20 > misunderstandings. > Comparing Guix' package definitions to other package managers=20 > makes it > obvious as to why that is the case. Let me pick Gentoo ebuilds=20 > as an > example (it's quicker to explain than whatever Debian has). > There are five (as opposed to three in Guix) kinds of=20 > dependencies: > - DEPEND, aka build-time dependencies, > - RDEPEND, aka run-time dependencies, > - BDEPEND, aka native build-time dependencies, > - IDEPEND, aka native install-time dependenices, and > - PDEPEND, aka what the fuck, I think I just introduced a cycle > somewhere. > When you say "build-time dependencies go into native inputs",=20 > someone > with a shallow understanding might think that *all* build time > dependencies are native inputs, when in fact only build time=20 > tools > (i.e. BDEPEND in Gentoo parlance) would go there. > > In other systems, it might be acceptable to have a package=20 > depend on > some other package without said dependency being present at=20 > build time. > Consider a shell script that wraps youtube-dl. Since youtube-dl=20 > exists > at some point between installation and first use, your shell=20 > script > works=E2=84=A2 whether or not youtube-dl is present at build. Some=20 > packages in > Guix do work that way, though it's a pretty rare occurrence.=20 > GStreamer > is one with a legitimate excuse, for example. Other than that,=20 > *all* > "dependencies" (actually inputs) are present at build time, so=20 > it makes > no sense to distinguish between build time and run time. Guix=20 > knows > which packages it can delete from the store by tracking=20 > references. > What Guix needs to distinguish is whether the package is invoked=20 > at > build time (native-inputs) or whether it needs to be installed > alongside the package being built (propagated-inputs) against=20 > none of > the two (regular inputs). IMHO, this kind of judgement arises from one's experience,=20 demands, intuition etc. I.e. personal perception. One could just make it=20 working somehow, another could have experience in what is being done,=20 another could stress things to the limits. If it would be up to me, I=20 would put everything into (native-inputs) and then gradually move things to (inputs) and (propagated-inputs) as needed (of course I'm not=20 doing that, I just want to show the point, that everybody's judgement is not the same :)). From what you are saying, if it is really=20 requires such level of control, I suppose that there should be a chapter in a guide on how to measure dependencies, with examples and=20 reasoning behind them, just like you mentioned GStreamer case, probably=20 updated with time from discussions like this. This could help to bring=20 people more or less on the same page. > So the next time you try to explain things to a first-timer, be=20 > clear > that native-inputs is for tools like compilers, linkers, code > generators *invoked* at build time. It will be less confusing=20 > to learn > it correctly the first time round rather than having to argue in=20 > the > mailing lists when submitting some patch. I understand that=20 > keeping > one piece of extra information in mind can be hard at times and=20 > the > temptation to simplify is always there, but in the long term no=20 > one > benefits from oversimplification. IMHO, for one it is unfair and/or unwise to treat everybody in the=20 same way, there could be one who barely saw compiler (if at all), and=20 one who did kernel development on embedded hardware :) I believe that, especially with new comers, it is always depends on case by case=20 basis. > Sorry for making you read this huge wall of text and happy=20 > hacking :) No issue, always good for practice, and history :)