Build both webkitgtk and webkitgtk3 with version 2.4.x, create new package(s) for later versions.

[roarde]

All builds against webkit* packages fail as of this date.

Here are the short form answers, I'll fill in any missing info if I get time.

Re-copy the webkitgtk and webkitgtk3 slackbuilds from 7.1. Both should be brought to latest stable 2.4.x version. They'll need editing, naturally. Both packages build from the same webkitgtk source, but would probably be difficult to build from the same slackbuild. Put strong notes on both that they should not be bumped past 2.4.x and will be retired when that version is no longer used. See https://lists.webkit.org/pipermail/webkit-gtk/2014-June/001947.html

To go forward with webkit, we'll need a new package. I suggest naming the webkitgtk packages by their main interface names in the future. I wouldn't change those mentioned above, but they make a good example. In this scheme, what we'll continue to call "webkitgtk" would still have been named "webkitgtk" (after webkit.1.0 -- a suffix of "1" is usually dropped); and what's "webkitgtk3" would still have been "webkitgtk3" (after its interface webkitgtk-3.0).

So far, the webkitgtk+ project has given each graphical output (such as gtk2 and gtk3, above) its own interface name (like webkit-1.0 or webkitgtk-3.0) each time. That name matches neither its webkit version nor its gtk version. That's not likely to change.

[hata_ph]

I notice webkitgtk and webkitgtk3 both build on gtk+3 for VL 7.2. Is that normal? Should it not webkitgtk build on gtk+2 and webkitgtk3 on gtk+3?

[roarde]

No, its not normal.

Yes, it should be as you say. Both of those should be built from the same 2.4.x source.

As far as a 2.10 package, I looked at some more information including our recent build of 2.10. The name for the new package should be "webkit2gtk". That's how the webkitgtk+ project has it in their API documentation headers, and that's been picked up by application developers when listing build requirements.

So what about mv'ing the "webkitgtk3" in our tree that was just used to build 2.10 to the name "webkit2gtk"? That would free up the "webkitgtk3" name to be used for the 2.4 build with gtk3.

Do not build the EFL interface from the webkitgtk+ sources. EFL webkit now has a home of its own, and that's what recent releases of EFL webkit applications like Midori use. We want a WebKitEFL, but I think it can wait.

[Moises Henriquez]

The following changes have been made to the vl72 repository.

• webkitgtk2 has been added. This is a compatibility that will build webkitgtk version 2.4.x against gtk+2 for apps that require that.
• webkitgtk3 has been reverted to version 2.4.9. This is another compatibility package that builds webkitgtk version 2.4.x but linked against gtk+3 for apps that require it.
• webkitgtk has been updated to version 2.10.x. This is the new pkg-config API (webkitgtk-4.0). Older applications will not build against this version.

Per the webkitgtk+ developers, applications depending on the compatibility packages should be updated (from their respective upstream) to build against the new stuff.

[hata_ph]

I have rebuild below pkgs that depend on the new webkitgtk2 in the 7.2 untested repo...pls let me know if there is any problem with the new pkgs...

• claws-mail-3.13.0 (NEW version)
• geany-plugins-1.25
• gimp-2.8.16
• gufw-15.10.0
• midori-0.5.11 (NEW version)

** I notice the current claws-mail-3.12.0 in 7.2 A0.3 do not use webkitgtk as dep. But i do build new claws-mail-3.13.0 with webkitgtk2 as dep. So if default 7.2 do not ship webkitgtk2 as default, I can rebuild claws-mail without webkitgtk2.

[Moises Henriquez]

<p dir="ltr">We can try claws during the alpha and beta test periods and see how it does</p>

[Former user]

roarde and m03 sorted this out