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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Freitag, den 17.09.2021, 17:11 +0300 schrieb muradm:
> [...]
> 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.
You can simply delete the generated configure file and Guix will
bootstrap it again.  So yes, you should be able to apply the upstream
patch.

> [...]
> Btw, gtk+'s native-inputs are interesting tho.. :)
In which way?

> [...]
> > 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 :)
This might be a bit pedantic, but *invoking* and *needing* are
different verbs, particularly in computing.  So no, you're just
confused and trying to justify your confusion.

> [...]
> > 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 :)). 
This reasoning is dangerously close to the "From my point of view" line
from a prequel to a famous space opera.

While yes, you do get an understanding of what belongs where over time,
the manual does provide guidelines that prohibit the "everything is
native" approach.

> 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.
GStreamer doesn't even concern the native-input vs. input dispute.  It
concerns the having something as an input vs. not having it.

> > 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.
I think when it comes to the point that you're packaging software for
any distro, you ought to be able to distinguish tools from things that
are not tools.  While I'm pretty sure that there are some entities out
there claiming that a bunch of XML files are a tool, I for one don't
think wayland-protocols does that.

Regards