[bug#50627] [PATCH 0/2] Make wayland-protocols dependency native-input.

[muradm <mail@muradm.net>]

Regardless of comments below, I understand what you are trying to 
point
out. It is fine with me to use 'inputs instead of 'native-inputs, 
as the
final result won't change. Just in my opinion, what I found it 
that, it
need/should not be in 'propagated-inputs. I will be updating the 
patch
to make sure that wayland-protocols are listed among 'inputs 
without
propagating. It is also fine with me to close this issue and don't 
do
anything if you say that it is unnecessary, I don't mind :)

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi
>
> Am Freitag, den 17.09.2021, 05:35 +0300 schrieb muradm:
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>>
>> > Hi,
>> >
>> > Am Donnerstag, den 16.09.2021, 22:23 +0300 schrieb muradm:
>> > > wayland-protocols is not runtime dependency and only build 
>> > > 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 
>> > > number of
>> > > dependants on it. But it turns out other way around. With 
>> > > this
>> > > patchset we are fixing gtk+ to not advertise it as 
>> > > dependency in
>> > > its .pc files, and moving wayland-protocols to 
>> > > 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 
>> > order
>> > to compile a package.  It doesn't seem to be the case that 
>> > 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 
>> are
>> used for code generation. We could consider them as a kind of
>> autoconf/bison like inputs, but tightly scoped for wayland 
>> needs,
>> although they are not so and not binaries.
> And what kind of code is generated from them?  I would assume 
> it's
> target code.  And since wayland-protocols is no tool to process 
> those
> XML files, but the files themselves, I'd hazard a guess that it 
> should
> rather be built for the target.  While currently this appears to 
> make
> no difference, there might well be a time in which those files 
> differ
> for some two architectures, which then would cause problems in 
> cross-
> compiling contexts were it a native input.
As with any other kind of protocol, you can implement platform 
specific
encoder/decoder, but protocol remains the same. Suppose, 
connecting from
arm, to x86 or vice versa in the context of wayland, should 
protocol
change? As you mentioned wayland-scanner below, that would be its 
task
to interpret protocol specification in 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.

>> > > Patch provided for gtk+ also merged with upstream.
>> > >
>> > > Patchset prepared from core-updates-frozen. While it seems 
>> > > that
>> > > it will impact many other packages, actually this patch 
>> > > reduces
>> > > number of packages that touches wayland-protocols and 
>> > > 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 
>> it was
>> before. I.e. wayland compositor, wayland application, wayland 
>> using
>> library, application which uses wayland using library, binary 
>> output
>> is not impacted. If binary output is the same, is there any 
>> 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 
> 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 
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, 
>> etc.
>> Second is propagation of inputs. Currently (without 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 either 
> (if we
> can) ignore pkg-config or patch the pkg-config files.  W.r.t. 
> pkg-
> config I do wonder whether Requires.private needs propagation, 
> though,
> it normally should be just 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 build tools. 
What
Guix's can do, it to fix what is already there. This patch 
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 
>> 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 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 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 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 
>> aware
>> of where/how this application is going to run, via xorg or 
>> wayland.
>> Then why I should be aware of 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 input? 
> 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 
>> files
>> any more 
>> (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. 
> 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 
>> > think we
>> > do need to be careful whenever "build time vs. run time" and 
>> > native
>> > vs. non-native are confused.
>> I'm using terminology as per documentation :) may be it should 
>> be
>> reworded in some other way to avoid confusion. 8.2.1 package
>> reference:
>>
>>           ‘native-inputs’ is typically used to list tools 
>>           needed
>>           at build time, but not at run time...
> You're quoting the manual out-of-context and (accidentally) 
> misuse the
> word tool.
>
>>           When cross-compiling, dependencies listed in ‘inputs’ 
>>           are
>>           built for the _target_ architecture; conversely,
>>           dependencies listed in ‘native-inputs’ are built for 
>>           the
>>           architecture of the _build_ machine.
> This is the distinction to make here.  "Typically used to list 
> tools"
> here means that the package provides a tool (i.e. a binary) that 
> you
> invoke at some point of your recipe.  This can be a compiler 
> like GCC,
> a tool to create Makefiles like automake, or an X server to 
> launch
> tests in.  The only thing in that regard when talking about 
> wayland
> would be the wayland-scanner tool provided by the wayland 
> package.
>
> Notice the contrast to what you said before with wayland being 
> an input
> and wayland-protocols being a native one.  If you need 
> 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 
> split for
> wayland might make sense.
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 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 
time"
or "dependency for host platform when crosscompiling" in reference 
to
'native-inputs. For instance when explaining this to one who sees 
Guix
for the first time, I would say "run time" for 'inputs and "build 
time"
for 'native-inputs, not mentioning "crosscompiling" at all on day 
one.
Any way, I beleive it is more like phylosophical subject, than 
technical.

> Regards