separate gtk4 from gtk-3

[juhp]

How do you think about making gtk4 is separate package from gtk-3?

I think GTK 3 and 4 will coexist for a long time, so while Hackage packages
can be parallel installed - for distros it is less simple: if we want to parallel
installing in Fedora for example we really need gi-gtk(3) and gi-gtk4.

This became more topical with the first official release of Gtk 4.0 recently.

[garetxe]

Hi!

I would not mind in principle (certainly not if this is really needed for packaging to be possible at all!), but I would like to understand the situation better, if you don't mind. Why is it not possible to have two fedora packages from different versions of the same hackage package? It feels a little bit strange to me having to use the name of the package to encode the major version, having a version field just for that.

One thing that worries me is that having separate packages, together with the original gi-gtk will be confusing for people, I'd rather avoid that. I guess I could deprecate gi-gtk in favour of gi-gtk(n), but that will be a little annoying for people who have to switch.

Would it be possible at all to create a fedora-gi-gtk-4 cabal package somewhere to work around the limitation in Fedora? Does it need to live in hackage?

Thanks!

[juhp]

We can think about it - it is not really urgent yet - gtk4 adoption is just in the early stage now.
Of course most distros will have separate packages for gtk3 and gtk4 I think (like gtk2).
It might be possible to override the Fedora Haskell packaging too to allow gi-gtk-4 to live in ghc-gi-gtk4 say
just it would need some extra work to handle this special case.

[juhp]

Also if you think in terms of Stackage, it would mean having to decide whether to use gtk3 or gtk4.
The differences between 3 and 4 are quite big in some areas, as you probably know,
so porting apps from 3 to 4 will be non-trivial in general.

Personally I would vote for moving to gi-gtk3 and gi-gtk4.
Well maybe just adding gi-gtk4 would be enough - no need to breaks all the gtk3 apps really, though it would be more consistent perhaps.

[garetxe]

Thanks for the comments! I am still a bit unclear, sorry. Is it technically not possible to have separate gi-gtk4.spec and gi-gtk3.spec files that wrap different versions of the same haskell package? (Perhaps Fedora is doing something more sophisticated than individual spec files?) At the level of Haskell one can have different versions installed, at least with the nix-style cabal store, but perhaps there is an issue installing things globally?

Also if you think in terms of Stackage, it would mean having to decide whether to use gtk3 or gtk4.

Yes, I was thinking about this. I agree that we'll need to choose, but it might actually be a good thing.

In fact, in the past I have considered removing the gi-* packages from stackage altogether. Keeping the haskell-gi and haskell-gi-base packages in stackage makes perfect sense (I do see the advantages of stackage in general) but I think that the gi-* packages are a bit of a special case: they are extremely stable, and newer versions simply add fixes for errors in the introspection data. There is very little need of a curated set of versions, in practice uploading to the latest version compatible with the haskell-gi version in stackage is always what you want. The downside of keeping the packages in stackage is that I get many issue reports from people using old stackage version with new system libraries: there are sometimes little errors in the introspection data that need to be patched by adding overrides. Easy to do, and I generally put a fixed version soon after I learn about the problem. But it might take months until people using stackage upgrade to the new versions, and their builds will break if they upgrade the system libraries in the meanwhile.

The biggest upside to keeping the gi-* packages in stackage, is that this way hoogle will index them. Definitely a good thing, and it supports the idea of having separate packages for separate major versions of gtk.

Anyway, this is just a long way to say that if someone sent a pull request for making separate gi-gtk4, gi-gdk4 and so on packages I will probably accept it for practical reasons, but I rather not do the work myself :)

[garetxe]

Just a thought: even if it's a little confusing, keeping gi-gtk generic (having both 3.0.x and 4.0.x versions) and then having specific version restricted variants as you suggest might work. We just need to put big disclaimers in the gi-gtkN packages that they are equivalent to doing gi-gtk == N.0.* in the .cabal file. This might make everyone happy? stackage would then carry gi-gtkN only, and similarly the fedora packages would carry gi-gtkN, but people using cabal or nix, which support multiple versions installed in parallel, can just use gi-gtk == N.0.*.

Does this sound reasonable?

[juhp]

Yeah that could work - but it makes app dependencies more awkward I fear?
Maybe I can try to tweak cabal-rpm to package by version when I find time later,
but it will be a little involved: I would like to have gi-gtk 4 in Fedora later this year if possible.

This may also affect Debian/Ubuntu - I don't know if Debian Haskell supports multiple lib versions -
I didn't see any examples at least.

Since gtk3 and gtk4 are basically incompatible I am not sure keeping them under the same gi-gtk
has real advantages though: I think only gtk is affected by this 3 -> 4 transition.

[juhp]

Anyway, this is just a long way to say that if someone sent a pull request for making separate gi-gtk4, gi-gdk4 and so on packages I will probably accept it for practical reasons, but I rather not do the work myself :)

I think I could certainly help with gi-gtk4.

Naively it looks like roughly all that is needed is sed s/gi-gtk/gi-gtk4/ bindings/Gdk-4.0/pkg.info.
Though it is probably a bit more than that?

I am slightly confused about gdk4 - I thought gtk4 uses gdk3 (at least in current Fedora), but I am no expert on this - maybe it can use either?

[garetxe]

Sorry for the slow reply!

I think I could certainly help with gi-gtk4.

Naively it looks like roughly all that is needed is sed s/gi-gtk/gi-gtk4/ bindings/Gdk-4.0/pkg.info.
Though it is probably a bit more than that?

On the technical side I think that's pretty much it :) The part that is less clear to me is the more "social" part, so to speak. It is a bit too late to get rid of gi-gtk, but in a few years people will expect gi-gtk to mean gtk4, not gtk3. So I think that I would like to keep the gi-gtk-4.0.* versions around (and eventually there will be 5.0 versions, I guess).

But, as you say, this is problematic for fedora and stack, which seem to have trouble with parallel installation. Having separate gi-gtk3-3.0.* and gi-gtk4-4.0.* in hackage would address this, but it would confuse people (should people use gi-gtk-4.0.* or gi-gtk4-4.0.*?). Particularly newcomers a couple of years from now, who will most likely install gi-gtk, expecting support for gtk4, and things will break in very confusing ways if they are really using gtk3 under the hood. Having a single package gives the latest version to newcomers, which is probably the least surprising choice, and it is easy to adapt old code that uses gtk3 by saying gi-gtk == 3.0.* in the cabal file. That's the theory anyway, I am sure that some people will get confused either way :)

So my preference, as it stands, would be to support just the latest (or no) version of gi-gtk in stackage (perhaps not now, but let's say in a year or so), and ask people to specify the other possibility, if they want, in the local stack.yaml.

Fedora is less clear to me, because I don't have a good idea of what's involved. Ideally it would be possible to generate gi-gtk4.rpm and gi-gtk3.rpm from the single gi-gtk hackage package, but I don't really know how difficult this is technically.

I am slightly confused about gdk4 - I thought gtk4 uses gdk3 (at least in current Fedora), but I am no expert on this - maybe it can use either?

This sounds surprising to me, I think that gtk4 does require gdk4. At least that's what the introspection data says:

  <include name="Gdk" version="4.0"/>

[juhp]

Coming back to this... Happy New Year!

I would like to move Stackage Nightly to gi-gtk-4 soon, but we can't because taffybar is still on gtk3 and probably will be for the foreseeable future...

As the maintainer also mentioned, I too really wish that haskell-gi would provide multiple versions of gtk (gtk3, gtk4 (and yes gtk5 will be coming)).
gtk3 and gtk4 are different enough that I think it is a requirement going forward.

[garetxe]

Happy New Year!

I agree, for stackage it seems necessary to provide separate gi-gtk3, gi-gtk4 packages (and a few others, I expect: gi-gdk and webkitgtk come to mind).

It is a bit of a question to me what to do with the packages without the version in the name. It seems reasonable to me to keep them functioning as they do now: gi-gtk-4.x would just re-export everything from gi-gtk4-4.x, and gi-gtk-3.x would re-export everything from gi-gtk3-3.x. Keeping the links in the haddock documentation working might also require a little work.

The other option is to do things the other way around: make gi-gtk3-3.x re-export everything from gi-gtk-3.x, and keep gi-gtk as the main package. We would then remove gi-gtk itself from stack, and ask people who want to have gi-gtk-3.x dependent packages in stackage to depend on gi-gtk3. Would this work? I don't know if technically stack can deal with this, but if so it might be a bit simpler.

Or, finally, we could just remove the gi-* packages from stackage. As I mentioned above, the gi-* packages are a little special, so I am not sure the benefits of stackage apply to them, and there are drawbacks with keeping them there. Is it possible to keep packages in stackage if their dependencies are not in stackage?

[juhp]

Happy New Year!

Thanks :-)

I agree, for stackage it seems necessary to provide separate gi-gtk3, gi-gtk4 packages (and a few others, I expect: gi-gdk and webkitgtk come to mind).

Right, and also for Linux distros, etc.

Actually porting apps from gtk3 to gtk4 is non-trivial: so consumers should expect to have to change the dependency.

It is a bit of a question to me what to do with the packages without the version in the name. It seems reasonable to me to keep them functioning as they do now: gi-gtk-4.x would just re-export everything from gi-gtk4-4.x, and gi-gtk-3.x would re-export everything from gi-gtk3-3.x. Keeping the links in the haddock documentation working might also require a little work.

I think this ^^ is the correct approach
(though personally I think in the longer term it would be better just to deprecate unversioned gi-gtk, etc in Hackage).

This will also be better when gtk5 appears. Dependent packages don't want to have to update their deps suddenly from gi-gtk to gi-gtk4, just because gtk5 appeared.

The other option is to do things the other way around: make gi-gtk3-3.x re-export everything from gi-gtk-3.x, and keep gi-gtk as the main package. We would then remove gi-gtk itself from stack, and ask people who want to have gi-gtk-3.x dependent packages in stackage to depend on gi-gtk3. Would this work? I don't know if technically stack can deal with this, but if so it might be a bit simpler.

I don't think that can work, since gi-gtk3 would depend on gi-gtk, right? So we are back to the same problem.

Or, finally, we could just remove the gi-* packages from stackage. As I mentioned above, the gi-* packages are a little special, so I am not sure the benefits of stackage apply to them, and there are drawbacks with keeping them there.

I feel that would be sad - I see a definite benefit in having gi-* in Stackage.

Is it possible to keep packages in stackage if their dependencies are not in stackage?

Not really, no

[jamesdbrock]

To me it’s very obvious that there must be separate packages for gtk3 and gtk4. But it's a lot of work. The best way to resolve this issue is to state that yes, the ideal situation is to separate the packages into gtk3 and gtk4. And then, once that goal is here in writing, perhaps someone will volunteer to do the work.

[garetxe]

Hi,

Could you please elaborate why you think separate packages are very obvious? Neither (modern) cabal nor ghc has any issue with parallel installation. The issues seem to be with stackage and rpm. I am honestly not sure having gi-* in stackage is a good idea, for the reasons above (to be clear, in general I do believe stackage is a great thing, but the guarantees it provides do not really apply to the gi-* packages, which autogenerate their own code on compilation, and installing the latest version is almost always the right thing to do). The main reason are the rpm packages, as I understand it, but I am honestly not sure how much of an issue it is, since I don't know how the rpm packages are generated.

In any case I am not opposed, I would be receptive to someone writing a PR along the following lines:

• Rename the current gi-gtk packages to gi-gtk3 and gi-gtk4, and similarly for gdk and any others that need it. This should be easy, the only issue is making sure that the haddocks don't break.
• Write a unnumbered package gi-gtk such that gi-gtk-3.0.* depends (and re-exports) gi-gtk3 == 3.0.*, gi-gtk-4.0.* depends on and re-exports gi-gtk4 == 4.0.*, etc. The haddocks here can just redirect to the appropriate packages.

The second one is probably not acceptable for stackage, but it's fine in hackage, and I'd like to keep it. It should be little extra work anyway.

[jamesdbrock]

Thanks @garetxe for all your work on this! It's a really great project.

[garetxe]

Thanks! :)

[amazari]

Hi!

FWIW, nixpkgs package is also suffering from the shared name for the two bindings.
Like Stackage or the rpm repo (I guess), it is a snapshot of the whole Hackage at one point in time. Only one version of a package can exist within a snapshot, and gi-gtk(3) is obviously the currently favored variant.
It make it at best tedious, if not impossible, to target gtk4 when using the cabal2nix facility.

Is there some work started on the solution proposed in @garetxe's previous comment? Any way one could help with the effort ?

[juhp]

@amazari I am not aware of any - been meaning to come back to this but not finding time ;-(

I would like to have gi-gtk-4 in Fedora as well as gi-gtk-3.
It would be nice to have them both in Stackage too.
And nixpkgs too

I think it is needed for most distros (except debian/ubuntu perhaps?)
Though I don't think even Debian Haskell has parallel versions?

[juhp]

@garetxe I appreciate your desire for backward-compatibility, but I feel offering two packages providing the same API with different names is probably worse and more confusing in the long-term. Some packages may choose to stay with gi-gtk and others switch gi-gtk4, etc.
As we know major gtk versions are fundamentally incompatible (and porting applications from 3 to 4 is non-trivial), so I still think it is better to bite the bullet and deprecate gi-gtk in a hardbreak in favour of gi-gtk3 and gi-gtk4 (and future gi-gtk5).

[garetxe]

@amazari There has been no progress on this as far as I am aware, but I am still supportive of the plan. I had hoped to look into this during the summer, but I couldn't find the time. And realistically I don't think I will have the time in the near future, so contributions are very much welcome!

@juhp Could you please elaborate about why you would like to have a hardbreak? I would very much like to avoid breaking backwards compatibility, but I have no feeling for how much work it would be to exclude the unversioned gi-gtk (and similar) versions from rpm packaging altogether.

[juhp]

Basically I think having 3 different upstream overlapping source packages is a bad idea: how to choose which to use?

Naively all that is really needed in the short term is two packages: one for v3 and one for v4. That will allow easy parallel packaging.

The simplest naive solution would be to either create gi-gtk3 or alternatively gi-gtk4 (but just the former is not a good long term solution as we discussed before: ie for v5).

I see in Repology.org that Arch/Manjaro/Parabola already have a forked (renamed) gi-gtk3. I could perhaps do that for Fedora too, but we can't for Stackage, unless someone uploads it to Hackage. Anyway it doesn't make sense for each distro to do this separately.