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

[muradm <mail@muradm.net>]

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.

>> 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.

>> 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?

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.

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.

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?

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).

I suppose that, initially wayland-protocols was listed in
propagated-inputs for this same reason, because gtk was 
advertising
it in .pc files.

> 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...

Thanks in advance,
muradm