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

[muradm <mail@muradm.net>]

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 
most
likely to remain leaf package, wlroots is different, we may look 
at
it later when updating it.

Thanks in advance,
muradm

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

> Hi,
>
> Am Freitag, den 17.09.2021, 11:20 +0300 schrieb muradm:
>> 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 :)
> I agree that reducing propagated-inputs is a good thing, it 
> should just
> be moved to inputs.  When you update the patch, please do use 
> the
> upstream version of gtk3-wayland-protocols-dependency.patch.
I suppose it is impossible, upstream patches are for source in 
git, gtk+
package is being built from post-processed source tarball. When 
patching
upstream target is configure.ac and meson.build, when patching 
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. 
>> 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.
> You are probably correct in that those files will likely stay 
> the same
> for all platforms, but there could be scenarios where for the 
> sake of
> performance or whatever else you might want to have some 
> protocol
> extensions.  Platforms that don't support those then wouldn't 
> 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 
>> > > 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.
> The point of authoring is a weird one when Guix can absolutely 
> still
> patch the file *and* you supplied a patch that was accepted 
> upstream.
> A patch, which mind you is arguably more correct than the one 
> you've
> supplied for Guix, patching the build files themselves rather 
> than
> generated sources.
>
> For other packages with similar issues without an upstream fix, 
> 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 
>> > > 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.
> 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 
other
time wayland-protocols package is needed. This is the reason why I
decided initially to keep it in (native-inputs), because 
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 
>> > > 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.
> This and that are different matters.  Application source code 
> continues
> to be blissfully unaware of the fact, but the toolchains to 
> build your
> application are not.  Think of it like this: When you use 
> pkg-config
> (or older -config binaries), they spit out a number of compiler 
> and
> linker flags to supply to gcc or ld.  You as the application 
> programmer
> are typically unaware of those flags and their values, 
> especially if
> you turn down the verbosity of your build system, but that 
> doesn't mean
> they're not supplied.
I don't know about typical programmer, for me as programmer, when 
I
write, I do look at every dependency and how it is included. This 
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 
>> 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 believe it is more like philosophical subject, than
>> technical.
> I think it is important to acknowledge that people come from 
> different
> backgrounds, and knowing that to do our best to curb 
> misunderstandings.
> Comparing Guix' package definitions to other package managers 
> makes it
> obvious as to why that is the case.  Let me pick Gentoo ebuilds 
> as an
> example (it's quicker to explain than whatever Debian has).
> There are five (as opposed to three in Guix) kinds of 
> 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", 
> someone
> with a shallow understanding might think that *all* build time
> dependencies are native inputs, when in fact only build time 
> tools
> (i.e. BDEPEND in Gentoo parlance) would go there.
>
> In other systems, it might be acceptable to have a package 
> depend on
> some other package without said dependency being present at 
> build time.
> Consider a shell script that wraps youtube-dl.  Since youtube-dl 
> exists
> at some point between installation and first use, your shell 
> script
> works™ whether or not youtube-dl is present at build.  Some 
> packages in
> Guix do work that way, though it's a pretty rare occurrence. 
> GStreamer
> is one with a legitimate excuse, for example.  Other than that, 
> *all*
> "dependencies" (actually inputs) are present at build time, so 
> it makes
> no sense to distinguish between build time and run time.  Guix 
> knows
> which packages it can delete from the store by tracking 
> references.
> What Guix needs to distinguish is whether the package is invoked 
> at
> build time (native-inputs) or whether it needs to be installed
> alongside the package being built (propagated-inputs) against 
> none of
> the two (regular inputs).
IMHO, this kind of judgement arises from one's experience, 
demands,
intuition etc. I.e. personal perception. One could just make it 
working
somehow, another could have experience in what is being done, 
another
could stress things to the limits. If it would be up to me, I 
would put
everything into (native-inputs) and then gradually move things to
(inputs) and (propagated-inputs) as needed (of course I'm not 
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 
requires
such level of control, I suppose that there should be a chapter in
a guide on how to measure dependencies, with examples and 
reasoning
behind them, just like you mentioned GStreamer case, probably 
updated
with time from discussions like this. This could help to bring 
people
more or less on the same page.

> So the next time you try to explain things to a first-timer, be 
> clear
> that native-inputs is for tools like compilers, linkers, code
> generators *invoked* at build time.  It will be less confusing 
> to learn
> it correctly the first time round rather than having to argue in 
> the
> mailing lists when submitting some patch.  I understand that 
> keeping
> one piece of extra information in mind can be hard at times and 
> the
> temptation to simplify is always there, but in the long term no 
> one
> benefits from oversimplification.
IMHO, for one it is unfair and/or unwise to treat everybody in the 
same
way, there could be one who barely saw compiler (if at all), and 
one
who did kernel development on embedded hardware :) I believe that,
especially with new comers, it is always depends on case by case 
basis.

> Sorry for making you read this huge wall of text and happy 
> hacking :)
No issue, always good for practice, and history :)