8:52 p.m.
Hi,
the latest webkitgtk package now uses the following subpackage names:
* webkit2gtk4.0 and webkit2gtk4.1 are for GTK 3,
* webkit2gtk5.0 are for GTK 4.
As you can see, the WebKitGTK soversion ends up appended to "gtk", making it
look like the package targets a different (higher) GTK version than it
actually does.
I can see why you want the soversion in there, especially to distinguish 4.0
from 4.1, but would it not make more sense to use:
webkit2gtk3_4.0
webkit2gtk3_4.1
webkit2gtk4_5.0
as the names?
Kevin Kofler
8:34 a.m.
I fear there's no non-confusing way to name these packages.
The theory behind the current naming was to stick as close as possible
to the upstream pkg-config versions, which are:
webkit2gtk-4.0 (GTK 3, libsoup 2)
webkit2gtk-4.1 (GTK 3, libsoup 3)
webkitgtk-5.0 (GTK 4, libsoup 3)
(webkitgtk-5.0 is still unstable and I just renamed it from
webkit2gtk-5.0 last week. That name change not yet reflected in Fedora
packaging.) Our packaging guidelines don't allow the use of the hyphen
in package names, so that character is removed, but otherwise the name
names match the pkg-config API version. I'm open to feedback on this,
but my opinion is that having a package name different from upstream
and different from what other distributions are doing is not
necessarily a good idea. For context, the Arch package names are:
webkit2gtk
webkit2gtk-4.1
webkit2gtk-5.0
And the Debian names are:
libwebkit2gtk-4.0-37
libwebkit2gtk-4.1-0
(Debian hasn't packaged -5.0 yet, and requires the soversion appended
to the package name.)
I previously proposed changing the GTK 4 API version from -5.0 to -4.5
so that we could sync up with GTK at -5.0, but didn't see much support
for the idea. Now would be a perfect time to do so, though, since this
API name was just changed a couple days ago anyway.
Michael
8:51 a.m.
Michael Catanzaro wrote:
And the Debian names are:
libwebkit2gtk-4.0-37
libwebkit2gtk-4.1-0
(Debian hasn't packaged -5.0 yet, and requires the soversion appended
to the package name.)
Debian is also notorious for having shipped kdelibs 3 as kdelibs4 and
kdelibs 4 as kdelibs5 due to the same soversion-based versioning policy.
That confused the heck out of users. (Fedora, on the other hand, used human-
readable versioning, so kdelibs 3 was and still is called kdelibs3, not
kdelibs4.) So I do not think Debian is a good example to follow.
Kevin Kofler
8:01 a.m.
If you test upgrades from f36 to f37 currently, you get:
webkit2gtk4.0.x86_64 2.37.91-1.fc37 replaces webkit2gtk3.x86_64 2.36.7-1.fc36
webkit2gtk4.1.x86_64 2.37.91-1.fc37 installed as upgrade
webkit2gtk5.0.x86_64 2.37.91-1.fc37 installed as upgrade
That surely is confusing, unless you've been reading-devel and remeber "something
about webkit versions".
What you write about the hyphen is certainly not true in that generality. In turn,
sticking those numbers right after "gtk" really cannot be read other than
"gtk4" and "gtk5", which is wrong.
How about something like webkit2gtk3so4.1 or webkit2gtk3-so4.1?
8:33 a.m.
On Mon, Sep 12, 2022 at 3:53 AM Kevin Kofler via devel <
devel(a)lists.fedoraproject.org> wrote:
Hi,
the latest webkitgtk package now uses the following subpackage names:
* webkit2gtk4.0 and webkit2gtk4.1 are for GTK 3,
* webkit2gtk5.0 are for GTK 4.
As you can see, the WebKitGTK soversion ends up appended to "gtk", making
it
look like the package targets a different (higher) GTK version than it
actually does.
I can see why you want the soversion in there, especially to distinguish
4.0
from 4.1, but would it not make more sense to use:
webkit2gtk3_4.0
webkit2gtk3_4.1
webkit2gtk4_5.0
as the names?
Thanks Kevin! I think what you are suggesting makes a lot of sense (but
it's one of few GNOME packages that I'm not calling the shots on and it's
Michael's call here).
By the way, do you have any suggestions for upstream library naming? There
is going to be an API break next cycle in the webkit2gtk-5.0 gtk4 API and
that's a good chance to do something about the shared library naming.
So far it's:
webkit2gtk-4.0.so
webkit2gtk-4.1.so
webkit2gtk-5.0.so
and I know Michael has been working on renaming webkit2gtk-5.0.so to
webkitgtk-5.0.so upstream. Can you come up with any better names for the
gtk4 shared library upstream, Kevin (or anyone else)? The constraint here
is that webkit2gtk-4.0.so and webkit2gtk-4.1.so are set in stone so it's
best to avoid something that can be easily confused with the existing
library names.
--
Kalev
8:49 a.m.
Thing is, it's confusing for every distro to use different names for
the same thing, like we did for webkit2gtk-4.0. But we seem to have all
standardized on using the pkg-config version for the package name now.
Consistency with other distros is worth a lot.
On Thu, Sep 15 2022 at 03:33:12 PM +0200, Kalev Lember
<kalevlember(a)gmail.com> wrote:
and I know Michael has been working on renaming webkit2gtk-5.0.so to
webkitgtk-5.0.so upstream.
Removing the 2 is already done.
I had a pet idea to change the API version to -4.5, so that we could
sync up with GTK 5 with -5.0, but this didn't seem popular upstream. So
now I'm toying with changing to -5.1 or -6.0 just to avoid confusion
caused by webkit2gtk-5.0 looking almost the same as webkitgtk-5.0.
I also considered webkitgtk4-1.0, to put the GTK API version into the
API name, but unfortunately this would be quite annoying to implement.
Removing the 2 was a lot of work :P and it's nicer to only vary the API
version at the end.
8:24 a.m.
On Thu, Sep 15 2022 at 08:49:39 AM -0500, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
I had a pet idea to change the API version to -4.5, so that we could
sync up with GTK 5 with -5.0, but this didn't seem popular upstream.
So now I'm toying with changing to -5.1 or -6.0 just to avoid
confusion caused by webkit2gtk-5.0 looking almost the same as
webkitgtk-5.0.
We discussed this upstream and settled on webkitgtk-6.0 as the name for
the GTK 4 API, to give slightly more distance between the GTK and
WebKitGTK API versions.
There was some interest in adding the GTK API version to the WebKitGTK
API version, like you suggested, but it's a little complicated and
there wasn't enough support to make this change.
I want the downstream package names to match the upstream API names as
closely as possible, so we can minimize the differences between Fedora
names and other distros' names. Being different than other distros is
most confusing of all!
Ideally we would exactly match the upstream name, webkitgtk-6.0. But
Kalev has pointed me to:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
as the guideline we followed when deciding to omit the hyphen.
Specifically:
"If the base package name does not end with a digit, the version MUST
be directly appended to the package name with no intervening separator."
So that's how we wound up with webkit2gtk4.0, webkit2gtk4.1,
webkit2gtk5.0 (current package name), and now webkitgtk6.0 (future
package name, to replace webkit2gtk5.0 in March). I'm not sure whether
that guideline is actually a good idea, as it results in our names
differing from other distros', but it's close enough.
One more note: the webkit2gtk5.0 package will disappear within the
lifetime of Fedora 37, so please don't actually use it. For now it's
required by Builder and gnome-initial-setup, which will require special
intervention when we update to WebKitGTK 2.40 in March. The goal is for
the API to be stable in WebKitGTK 2.40, so holding off until then will
help avoid trouble.
Michael
8:29 a.m.
On Tue, Sep 20 2022 at 08:24:32 AM -0500, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
Being different than other distros is most confusing of all!
BTW part of the confusion here might be that you're used to the Fedora
package name, webkit2gtk3. But all other distros just called it
webkit2gtk. I want to avoid Fedora-specific things with the names this
time around.
10:05 a.m.
Hi,
On Tue, 2022-09-20 at 08:24 -0500, Michael Catanzaro wrote:
For now it's required by Builder and gnome-initial-setup
... and evolution-data-server, according to:
dnf repoquery --alldeps --whatrequires "webkit2gtk5.0"
and
dnf repoquery --alldeps --whatrequires "pkgconfig(webkit2gtk-5.0)"
Thus some upstream changes will be needed there too. The transition
will be painful, if the upstream is supposed to support both naming-s.
Bye,
Milan
12:36 p.m.
OK, thanks for the heads-up. I didn't notice this because I was looking
at the GNOME build rules, where evolution-data-server does not yet
depend on it. We'll need to coordinate with you to ensure the 2.38 ->
2.40 update goes smoothly, then. I don't expect this to be difficult:
it should be simple changes only. Just need to be sure WebKitGTK,
Builder, evolution-data-server, and gnome-initial-setup are all bundled
into the same bodhi update.
On Tue, Sep 20 2022 at 05:05:38 PM +0200, Milan Crha <mcrha(a)redhat.com>
wrote:
Thus some upstream changes will be needed there too. The transition
will be painful, if the upstream is supposed to support both naming-s.
No, there will be zero upstream support for webkit2gtk-5.0: it is
actually already gone, replaced by webkitgtk-6.0. webkit2gtk-5.0 is was
a WIP/unstable/development API, and 2.38 will be the last release with
it available. I wanted to stabilize it in time for 2.38, but failed.
I am pretty sure that webkitgtk-6.0 will be stable in time for 2.40,
though. I'm actively working on this now. The goal will be to provide
API and ABI stability for as long as possible, same as webkit2gtk-4.0
and webkit2gtk-4.1.
Michael
7:59 p.m.
Michael Catanzaro wrote:
Being different than other distros is most confusing of all!
I have to disagree with that blanket assertion.
E.g., I believe it would have been much more confusing for our users if we
had shipped kdelibs 3.5.x as kdelibs4 (or "kdelibs4c2a" as Debian actually
called it, because they also handled a libstdc++ soname bump in a totally
weird way) rather than kdelibs3 as we did.
I believe version numbers should be human-readable, not reflect the internal
soname when they differ, even if that means we use a different package name
than distributions like Debian stubbornly sticking to soname-based
versioning.
Kevin Kofler
619
days inactive
628
days old
12 comments
5 participants
participants (5)
-
Kalev Lember -
Kevin Kofler -
Michael Catanzaro -
Michael J Gruber -
Milan Crha