Message ID | 20210426081145.28926-5-rg@raghavgururajan.name |
---|---|
State | Accepted |
Headers | show |
Series | [bug#48028,wip-gnome,1/8] gnu: gtkmm@2: Remove inheritance from gtkmm@3. | expand |
Context | Check | Description |
---|---|---|
cbaines/submitting builds | success | |
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
cbaines/issue | success | View issue |
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.
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 #: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) ("libpsl" ,libpsl) ("libxml2" ,libxml2) ("sqlite" ,sqlite) ("zlib" ,zlib))) (inputs - `(("glib-networking" ,glib-networking) - ("mit-krb5" ,mit-krb5))) + `(("mit-krb5" ,mit-krb5) + ("ntlm_auth" ,samba))) (home-page "https://live.gnome.org/LibSoup/") (synopsis "GLib-based HTTP Library") (description