[bug#48028,wip-gnome,5/8] gnu: libsoup: Add missing argument and input.

Propagate glib-networking as per .pc file.

* gnu/packages/gnome.scm (libsoup)[arguments](glib-or-gtk): New argument.
[inputs]: Add samba. Move glib-networking to ...
[propagated-inputs]: ... here.
---
 gnu/packages/gnome.scm | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

This headline does not match the contents of the patch.

Am Montag, den 26.04.2021, 04:11 -0400 schrieb Raghav Gururajan:
> Propagate glib-networking as per .pc file.
This looks like it could be its own patch were it not for the fact,
that samba needs to be added as well (what for?)

> * gnu/packages/gnome.scm (libsoup)[arguments](glib-or-gtk): New
> argument.
> [inputs]: Add samba. Move glib-networking to ...
> [propagated-inputs]: ... here.
> ---
>  gnu/packages/gnome.scm | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
> index 29779c39af..b69980091b 100644
> --- a/gnu/packages/gnome.scm
> +++ b/gnu/packages/gnome.scm
> @@ -4913,7 +4913,7 @@ libxml to ease remote use of the RESTful API.")
>       `(#:modules ((guix build utils)
>                    (guix build meson-build-system)
>                    (ice-9 popen))
> -
> +       #:glib-or-gtk? #t ; To wrap binaries and/or compile schemas
That doesn't sound very sure to me.  Why are you wrapping binaries
and/or compiling schemas?
>         #:configure-flags '("-Dgtk_doc=true")
>         #:phases
>         (modify-phases %standard-phases
> @@ -4964,13 +4964,14 @@ libxml to ease remote use of the RESTful
> API.")
>       ;; libsoup-2.4.pc refers to all these.
>       `(("brotli" ,google-brotli)
>         ("glib" ,glib)
> +       ("glib-networking" ,glib-networking)
I haven't checked, but if the .pc file says so, so be it.
>         ("libpsl" ,libpsl)
>         ("libxml2" ,libxml2)
>         ("sqlite" ,sqlite)
>         ("zlib" ,zlib)))
>      (inputs
> -     `(("glib-networking" ,glib-networking)
> -       ("mit-krb5" ,mit-krb5)))
> +     `(("mit-krb5" ,mit-krb5)
> +        ("ntlm_auth" ,samba)))
Careful with the indentation.
>      (home-page "https://live.gnome.org/LibSoup/")
>      (synopsis "GLib-based HTTP Library")
>      (description

Regards,
Leo

Hi Leo!

> This looks like it could be its own patch were it not for the fact,
> that samba needs to be added as well (what for?)

I have split them into two patches and added comment, in v3.

> That doesn't sound very sure to me.  Why are you wrapping binaries
> and/or compiling schemas?

It is mainly for compiling schemas, as libsoup doesn't have binaries to 
wrap. But I just now realized that there is no 
`[out]/share/glib-2.0/schemas` either. So I removed this in v3.

> Careful with the indentation.

Ah, good catch. I have fixed it in v3.

Thanks!

Regards,
RG.

Am Montag, den 26.04.2021, 05:28 -0400 schrieb Raghav Gururajan:
> Hi Leo!
> 
> > This looks like it could be its own patch were it not for the fact,
> > that samba needs to be added as well (what for?)
> 
> I have split them into two patches and added comment, in v3.
> 
> > That doesn't sound very sure to me.  Why are you wrapping binaries
> > and/or compiling schemas?
> 
> It is mainly for compiling schemas, as libsoup doesn't have binaries
> to 
> wrap. But I just now realized that there is no 
> `[out]/share/glib-2.0/schemas` either. So I removed this in v3.
> 
> > Careful with the indentation.
> 
> Ah, good catch. I have fixed it in v3.
v3 06/07 LGTM, but could in my opinon be merged into a single patch
with the line: "gnu: libsoup: Add missing inputs." or perhaps "gnu:
libsoup: Adjust inputs".  I've CC'd Mark Weaver to hear their input.

Regards,
Leo

Hi Leo!

> v3 06/07 LGTM, but could in my opinon be merged into a single patch
> with the line: "gnu: libsoup: Add missing inputs." or perhaps "gnu:
> libsoup: Adjust inputs".  I've CC'd Mark Weaver to hear their input.

Makes sense! I have merged the changes into single patch, in v4.

Regards,
RG.

Hi Raghav,

Version 4 of your patch set mostly looks good to me, but I have one
concern about patch 3 (gnu: gtkmm: Add missing native-input and correct
propagated-inputs).

That patch modifies the 'propagated-inputs' field of 'gtkmm' to refer to
specific versions of packages: 'atkmm-2.28', 'cairomm-1.13', and
'pangomm-2.42'.  These references to specific versions are not ideal,
because:

(1) They will likely lead to conflicts within profiles.  For example, a
profile that includes both 'gtkmm' and 'cairomm' may fail to build,
because it would require including both 'cairomm' and 'cairomm-1.13',
and

(2) We might forget to update these references in the future.

It would be good to avoid these version-specific references, if
possible.  Can you help me understand the rationale?  Did you find that
there is an incompatibility between the latest stable versions of
'gtkmm', 'atkmm', 'cairomm', and 'pangomm'?  If so, could you help me
understand the nature of that incompatibility?  Perhaps it can be
addressed in another way.

If it turns out that these versioned references are truly unavoidable,
it would be good to add comments next to those references, briefly
explaining the rationale.

Thanks very much for your work on this, Raghav.

     Regards,
       Mark

Hi Mark,

> It would be good to avoid these version-specific references, if
> possible.  Can you help me understand the rationale?  Did you find that
> there is an incompatibility between the latest stable versions of
> 'gtkmm', 'atkmm', 'cairomm', and 'pangomm'?  If so, could you help me
> understand the nature of that incompatibility?  Perhaps it can be
> addressed in another way.

Its because of ABI incompatibility. The pkg-config for gtkmm, checks for 
specific ABI versions of atkmm, cairomm and pangomm.

> If it turns out that these versioned references are truly unavoidable,
> it would be good to add comments next to those references, briefly
> explaining the rationale.

I have added comment in the code, in v5.

Regards,
RG.

Hi Raghav,

Raghav Gururajan <rg@raghavgururajan.name> writes:

>> It would be good to avoid these version-specific references, if
>> possible.  Can you help me understand the rationale?  Did you find that
>> there is an incompatibility between the latest stable versions of
>> 'gtkmm', 'atkmm', 'cairomm', and 'pangomm'?  If so, could you help me
>> understand the nature of that incompatibility?  Perhaps it can be
>> addressed in another way.
>
> Its because of ABI incompatibility. The pkg-config for gtkmm, checks for 
> specific ABI versions of atkmm, cairomm and pangomm.
>
>> If it turns out that these versioned references are truly unavoidable,
>> it would be good to add comments next to those references, briefly
>> explaining the rationale.
>
> I have added comment in the code, in v5.

Respectfully, it seems to me that you've been too quick to dismiss my
concerns.  As I pointed out in my previous email:

  (1) [These versioned references] will likely lead to conflicts within
  profiles.  For example, a profile that includes both 'gtkmm' and
  'cairomm' may fail to build, because it would require including both
  'cairomm' and 'cairomm-1.13',

This could be a real annoyance.  Guix users should be able to run "guix
install gtkmm atkmm cairomm pangomm" and have that work.  With these
proposed patches applied, I suspect that it might not work.

Traditional GNU/Linux distributions that package GNOME 40 will certainly
choose versions of 'gtkmm', 'atkmm', 'cairomm', and 'pangomm' that are
compatible with each other.  We should too, I think.

From my own experience performing a GNOME upgrade for Guix a few years
ago, I remember that when the GNOME developers produce a new GNOME
release, they provide somewhere a list of the versions of each component
that are part of that release.  Presumably they choose those versions to
be compatible with each other.

This makes me wonder if some of the GNOME components on the 'wip-gnome'
branch are newer than they should be (perhaps a development version) or
older than they should be.

What do you think?

    Regards,
      Mark

Hi Mark!

> Respectfully, it seems to me that you've been too quick to dismiss my
> concerns.  As I pointed out in my previous email:
> 
>    (1) [These versioned references] will likely lead to conflicts within
>    profiles.  For example, a profile that includes both 'gtkmm' and
>    'cairomm' may fail to build, because it would require including both
>    'cairomm' and 'cairomm-1.13',

I didn't dismiss your concerns. Since you mentioned "If it turns out 
that these versioned references are truly unavoidable [...]", at the 
time of my reply, I was convinced that its unavoidable.


> This could be a real annoyance.  Guix users should be able to run "guix
> install gtkmm atkmm cairomm pangomm" and have that work.  With these
> proposed patches applied, I suspect that it might not work.
> 
> Traditional GNU/Linux distributions that package GNOME 40 will certainly
> choose versions of 'gtkmm', 'atkmm', 'cairomm', and 'pangomm' that are
> compatible with each other.  We should too, I think.
> 
>  From my own experience performing a GNOME upgrade for Guix a few years
> ago, I remember that when the GNOME developers produce a new GNOME
> release, they provide somewhere a list of the versions of each component
> that are part of that release.  Presumably they choose those versions to
> be compatible with each other.
> 
> This makes me wonder if some of the GNOME components on the 'wip-gnome'
> branch are newer than they should be (perhaps a development version) or
> older than they should be.
> 
> What do you think?

I tried dirty hack of patching meson.build of gtkmm, to refer to latest 
versions of cairomm, atkmm, pangomm. Though, 'configure phase passes, 
'build phase fails with *numerous* errors.

If I de-propagate those inputs, packages that depends on gtkmm via 
pkg-config, gonna barf "gtkmm not found".

Do you have any ideas?

Regards,
RG.

Hi Mark!

> I tried dirty hack of patching meson.build of gtkmm, to refer to latest 

> versions of cairomm, atkmm, pangomm. Though, 'configure phase passes, 
> 'build phase fails with *numerous* errors.
> 
> If I de-propagate those inputs, packages that depends on gtkmm via 
> pkg-config, gonna barf "gtkmm not found".
> 
> Do you have any ideas?

Libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each 
other's latest stable version. The gtkmm is the only outlier.

So I think we can either de-propagate inputs in gtkmm or use the patch 
as-is; and revert changes when new gtkmm version is released.

WDYT?

Regards,
RG.

Hi Mark,

>> I tried dirty hack of patching meson.build of gtkmm, to refer to latest 
> 
>> versions of cairomm, atkmm, pangomm. Though, 'configure phase passes, 
>> 'build phase fails with *numerous* errors.
>>
>> If I de-propagate those inputs, packages that depends on gtkmm via 
>> pkg-config, gonna barf "gtkmm not found".
>>
>> Do you have any ideas?
> 
> Libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each 
> other's latest stable version. The gtkmm is the only outlier.
> 
> So I think we can either de-propagate inputs in gtkmm or use the patch 
> as-is; and revert changes when new gtkmm version is released.
> 
> WDYT?

I just realized packages that depend on gtkmm, doesn't propagate it. So 
only way gtkmm, ends up in user-profiles is when explicitly installed. 
Thus conflicts doesn't happen while building profiles right?

Regards,
RG.

Hi Mark, Leo and Tobias:

>>> I tried dirty hack of patching meson.build of gtkmm, to refer to latest 
>>
>>> versions of cairomm, atkmm, pangomm. Though, 'configure phase passes, 

>>> 'build phase fails with *numerous* errors.
>>>
>>> If I de-propagate those inputs, packages that depends on gtkmm via 
>>> pkg-config, gonna barf "gtkmm not found".
>>>
>>> Do you have any ideas?
>>
>> Libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each 
>> other's latest stable version. The gtkmm is the only outlier.
>>
>> So I think we can either de-propagate inputs in gtkmm or use the patch 

>> as-is; and revert changes when new gtkmm version is released.
>>
>> WDYT?
> 
> I just realized packages that depend on gtkmm, doesn't propagate it. So 

> only way gtkmm, ends up in user-profiles is when explicitly installed. 
> Thus conflicts doesn't happen while building profiles right?

After this 
(https://mail.gnome.org/archives/gtkmm-list/2021-May/msg00000.html), 
what do you think of following plan?

[1] Temporarily have the gtkmm patch as-is in c-u
[2] package gtk (v4)
[3] rename gtkmm to gtkmm-3
[4] package gtkmm (v4).

So at the end these steps, glibmm, cairomm, pangomm, atkmm and gtkmm can 
exist in same profile without conflicts.

Regards,
RG.

Hi Raghav,

Raghav Gururajan <rg@raghavgururajan.name> writes:

> Libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each 
> other's latest stable version. The gtkmm is the only outlier.

Is there a stable release version of gtkmm that plays well with those
others?

Thanks for looking into this, Raghav.

      Mark

Hi Mark,

>> Libsigc++, glibmm, cairomm, pangomm and atkmm; play well with each
>> other's latest stable version. The gtkmm is the only outlier.
> 
> Is there a stable release version of gtkmm that plays well with those
> others?

Unfortunately no. :(

Regards,
RG.

Hi Raghav,

Raghav Gururajan <rg@raghavgururajan.name> writes:

> I just realized packages that depend on gtkmm, doesn't propagate it. So 
> only way gtkmm, ends up in user-profiles is when explicitly installed. 
> Thus conflicts doesn't happen while building profiles right?

You might be right for users who only install user applications.

However, if I understand correctly, with the v4 patches that I looked at
earlier, and presumably also the v5 patches (based on what you wrote), I
guess that conflicts _would_ happen if someone tries to install 'gtkmm'
and 'cairomm' together in the same profile.  It would be good to make
that work properly, by selecting appropriate versions of these *mm
packages that are compatible with each other.

What do you think?

      Regards,
        Mark

Am Freitag, den 07.05.2021, 14:40 -0400 schrieb Mark H Weaver:
> Hi Raghav,
> 
> Raghav Gururajan <rg@raghavgururajan.name> writes:
> 
> > I just realized packages that depend on gtkmm, doesn't propagate
> > it. So 
> > only way gtkmm, ends up in user-profiles is when explicitly
> > installed. 
> > Thus conflicts doesn't happen while building profiles right?
> 
> You might be right for users who only install user applications.
> 
> However, if I understand correctly, with the v4 patches that I looked
> at
> earlier, and presumably also the v5 patches (based on what you
> wrote), I
> guess that conflicts _would_ happen if someone tries to install
> 'gtkmm'
> and 'cairomm' together in the same profile.  It would be good to make
> that work properly, by selecting appropriate versions of these *mm
> packages that are compatible with each other.
> 
> What do you think?
> 
>       Regards,
>         Mark
As an addendum to what Mark said, I think this could be achieved by
temporarily hiding the variants of atkmm, cairomm, etc. that are
supposed to go with the yet unpackaged gtkmm and perhaps doing a round
of variable renames, so that those using manifests won't be screwed
either.