Created attachment 421564 [details, diff] subslot-x11-libs-gtk-3.patch This idea was originally floated a few weeks/months ago. MATE has some packaging quirks that make it GTK+:3 branch dependent, so after some considering, the MATE project team decided that this option would be most effective and serve us best. Obviously, it'd be faily trivial to use versionator to construct the subslot so less effort is required by maintainers, but I figured I'd leave that decision up to you since that would involve including a new eclass. I can draft up a new patch if you would like. Replicating logic from patch commit message: The goal of this subslot is to allow other packages to determine what minor version of gtk+:3 is installed so that they can operate accordingly. This functionality is extremely desirable as there are often incompatible changes between gtk+:3 branches. This functionality enables an ebuild to make decisions based on the branch via has_version or best_version queries during phases. The best way to take advantage of this functionality is DEPEND="x11-libs/gtk+:3=" or similar. This has the obvious issue that there is no guarantee that the subslot will be consistent throughout the phases of the ebuild, however, because of the subslot rebuild operator, the package manager should force rebuilding ebuild in question.
I think this idea is wrong because it assumes they are many incompatible changes while gtk+ and Gnome in general take very serious care of API/ABI compatibility of their library. Experience shows this is unfortunately not so true for their theme engine but adding subslots and possibly triggering hundreds of package rebuilds on gtk+ upgrades, because not all our fellow devs understand when to use subslots and when not to, just to make theming more manageable seems like a big no-no to me. I would rather have a virtual/meta ebuild defining a proper slot for theming only.
(In reply to Gilles Dartiguelongue from comment #1) > I think this idea is wrong because it assumes they are many incompatible > changes while gtk+ and Gnome in general take very serious care of API/ABI > compatibility of their library. > > Experience shows this is unfortunately not so true for their theme engine > but adding subslots and possibly triggering hundreds of package rebuilds on > gtk+ upgrades, because not all our fellow devs understand when to use > subslots and when not to, just to make theming more manageable seems like a > big no-no to me. > > I would rather have a virtual/meta ebuild defining a proper slot for theming > only. Yeah, I must say, I'm mostly working off of what upstream MATE is telling me, as my experience in the matter is a little limited. If your suggestion is a virtual/meta for MATE theming, I can do that. I know that people are also generally against adding new virtuals as well. But if you think that is the best approach, I defer to your logic and experience and will ask about it on the ML as is std procedure for adding a new virtual.
(In reply to Gilles Dartiguelongue from comment #1) > I would rather have a virtual/meta ebuild defining a proper slot for theming > only. The only real problem that I have with this approach is that it leads to a proliferation of ebuilds. Right now, there are only 2 gtk+:3 branches, but for 2 MATE releases, that's 4 ebuilds right there. At one point there was the potential for there to be 6. We'd end up with virtual/mate-themes and x11-themes/mate-themes-1.10_3.16, x11-themes/mate-themes-1.10_3.18 x11-themes/mate-themes-1.12_3.16 x11-themes/mate-themes-1.12_3.18.
imho the simplest approach is to always target the same keywording as gtk+3 release that matches your themes. Stabilization in Gnome is pretty easy to track, we bump and stabilize new releases of Gnome about every six month with 2-3 months shift from Gnome upstream.
(In reply to Gilles Dartiguelongue from comment #4) > imho the simplest approach is to always target the same keywording as gtk+3 > release that matches your themes. Stabilization in Gnome is pretty easy to > track, we bump and stabilize new releases of Gnome about every six month > with 2-3 months shift from Gnome upstream. The biggest problem I think I have with that is that MATE's release cycle isn't synced with GTK/GNOME's. If we are out of sync, that means users get stuck in the situation of having to downgrade from unstable gtk+3 to stable gtk+3 if a MATE stablization happens. For the sake of autonomy and user choice, I feel like the virtual is probably best. At least for my own sanity's sake, I can make a generic ebuild that calculates the values based on PV and so I only need to maintain 1 ebuild. Side note, thank you for your feedback and input.
Are that breakages in gtk+ theming so frequent and affecting so hard to MATE? I remember to hear about this issue long time ago, but, in that cases, the reverse deps that got broken could be easily patches to work with latest gtk+ versions without much problems :/ I mean, what concrete problem are you hitting in MATE vs. GTK+ 3.x? Thanks for the info :)
(In reply to Pacho Ramos from comment #6) > Are that breakages in gtk+ theming so frequent and affecting so hard to > MATE? I remember to hear about this issue long time ago, but, in that cases, > the reverse deps that got broken could be easily patches to work with latest > gtk+ versions without much problems :/ > > I mean, what concrete problem are you hitting in MATE vs. GTK+ 3.x? > > Thanks for the info :) So, upstream MATE has stated that between branchs of GTK+ 3, things in themes like menubars breaking and weird other distortions. The packaging issue is as follows: Upstream doesn't release a single tarball for mate-themes. They release one per branch, per gtk+3 branch. so, mate-themes-1.10-3.{8,10,12,14,16,18} and mate-themes-1.12-{12,14,16,18}. So I need some reasonable means of choosing the appropriate tarball, and ensuring that it works with the user's installed gtk+:3. Because we are likely to have a version of MATE in stable, and a version in unstable, and because MATE releases aren't aligned with GTK/GNOME releases, tracking stable GNOME/GTK isn't really reasonable/feasible. So, my intent was to come up with a way of choosing the appropriate tarball based on what the user has installed.
(In reply to NP-Hardass from comment #7) > so, mate-themes-1.10-3.{8,10,12,14,16,18} > and mate-themes-1.12-{12,14,16,18}. I would then make that themes rdepend on the concrete gtk+3 version they are prepared to work for, I mean, mate-themes-1.10.3.8 would need ~x11-libs/gtk+-3.8 and so I think I have seen that issue solved in that same way in another theme pack (one called Clear... well, a theme that was trying to mimic the old gtk2 clearlooks theme for gtk3) That would be much more "predictable" and understandable than portage dying randomly because of some unresolved subslot blockers when people try to mix gtk3 and that themes randomly. Additionally, when portage will die, it will clearly state what concrete theme forces the usage of a concrete gtk+3 version instead of showing the usual burst of blocking errors that are much hardly to understand for the users
(In reply to Pacho Ramos from comment #8) > (In reply to NP-Hardass from comment #7) > > so, mate-themes-1.10-3.{8,10,12,14,16,18} > > and mate-themes-1.12-{12,14,16,18}. > > I would then make that themes rdepend on the concrete gtk+3 version they are > prepared to work for, I mean, mate-themes-1.10.3.8 would need > ~x11-libs/gtk+-3.8 and so > > I think I have seen that issue solved in that same way in another theme pack > (one called Clear... well, a theme that was trying to mimic the old gtk2 > clearlooks theme for gtk3) > > That would be much more "predictable" and understandable than portage dying > randomly because of some unresolved subslot blockers when people try to mix > gtk3 and that themes randomly. Additionally, when portage will die, it will > clearly state what concrete theme forces the usage of a concrete gtk+3 > version instead of showing the usual burst of blocking errors that are much > hardly to understand for the users Does this require use of a virtual? Consider the following example: gtk+-3.16 and gtk+-3.18 both are stable. If they user has gtk+-3.16 installed, mate-themes-1.10.3.16 is < mate-themes-1.10.3.18. Is the PM going to have issues selecting the lower version? Is this resolved and/or better handled by a virtual that has: ^^ ( ( gtk+-3.16 mate-themes-1.10.3.16 ) ( gtk+-3.18 mate-themes-1.10.3.18 ) )
I fail to see how that overcomplex dependency (and also adding that layer of the virtual) is better than simply specifying the ~x11-libs/gtk+3-xxx deps in mate themes :| With the deps as I am suggesting, people emerging older mate-themes version requiring older gtk+ version will simply try to downgrade gtk+ (as wanted), then, I don't see what problem is pending to handle :(
Can't you just have different revisions of mate-themes for each gtk version needed; perhaps only maintain a minimum gtk dependency in them (as locking to a certain version could complicate upgrade cycles) and ask us to keep keywording of these appropriately synced as we introduce next gtk cycle to stable or so? Like mate-themes-1.12-r160 would depend on >=gtk+-3.16:3 and mate-themes-1.12-r180 would depend on >=gtk+-3.18:3 and you ask us to get -r180 stabilized together with gtk+-3.18? With current upstream gtk efforts to move everything over to CSS and actually document the theming keywords (CSS classes) to use and maintain backwards compatibility from there on, this hopefully won't be a long term issue anymore either.
(r160 meaning 3.16, with 0 meant as a spacer, so you can do actual revision changes as r161 and whatnot - could be some other kind of versioning as well, but this is increasing from 160 to 180, so as long as visibility matches, users will get an upgrade to r180 together with gtk+-3.18 as both get stabilized at the same time, as long as they deep upgrade the world at least)
(In reply to Mart Raudsepp from comment #12) > (r160 meaning 3.16, with 0 meant as a spacer, so you can do actual revision > changes as r161 and whatnot - could be some other kind of versioning as > well, but this is increasing from 160 to 180, so as long as visibility > matches, users will get an upgrade to r180 together with gtk+-3.18 as both > get stabilized at the same time, as long as they deep upgrade the world at > least) As much as I don't like it, I ended up with this solution. Thanks to all for the input.
(wontfix solution then as, per summary, that is "wontfix", otherwise it can lead people to think that subslot was added finally :/)
