On 26-08-2022 18:59, muradm wrote:
> As far as I understand, this one is to reduce dependencies of
> wayland-protocols itself. 

This one keeps the dependencies the same (except for pkg-config / 
pkg-config-for-build) -- it just sorts the dependencies differently.

> As far as I know, there is no binary output of wayland-protocols,

'ls -R "$(guix build wayland-protocols)"'? Maybe not 'binary', but it 
still appears required by some dependents.

> and wayland maybe needed as dependency for testing purposes only. 
This appears confirmed by meson.build. In that case, wayland can be 
removed from 'inputs' and put in 'native-inputs' unconditionally.

Tobias, does unconditionally moving wayland from 'inputs' to 
'native-inputs' (and unconditionally using pkg-config-for-build) work? 
Potential problem: lots of dependents according to "guix refresh -l", 
making it unconditional would need to be done on core-updates or staging.

> IMHO these tests are targeted for developers producing protocol
> specifications. Once protocol specification is ready
> wayland-protocols is released. So running tests on
> wayland-protocols should be pointless waste of resources, as they
> don't prove that anything useful, instead dependents should
> test themselves. If testing causing waste of space and resources
> I would turn them off or probably use copy-build-system even. 
#:tests? #false should suffice, no need to switch to copy-build-system.

I see the argument for a waste of CPU time/energy resources, but not for 
a waste of space.

Also, it is a dangerous assumption to make that developers run tests 
prior to a release. It seems pretty logical to me to do that, but 
sometimes errors are encountered in Guix and discussions happen upstream 
that indicate that this somehow didn't happen.

Even if developers are known to always run tests, without fail, they 
might run tests in a different environment.

For example, until recent-ish, GCC did -fcommon as a default, but later 
switched to -fcommon, breaking some builds.

Also, 'developers' is not necessarily 'upstream developers'. Sometimes 
Guix adds a patch to package definitions, in combinations that upstream 
might not have tested, in that case running tests is important. 
Additionally, sometimes I find it more practical to write a patch, add 
it to the package definition and do a "guix build", than to do 
whatever's the meson equivalent of 'make && make check'.

Greetings,
Maxime.