Red Hat Bugzilla – Bug 442200
RFE: WebKit Migration
Last modified: 2008-07-27 00:29:50 EDT
Current rawhide Qt builds Conflict with WebKit-qt. However, since that stuff is
moving into Qt proper soon, we should properly move it in the packaging for F-10.
That is, after F9 goes GA and we get rawhide eating babies again, we should I
can remove the Qt building from the WebKit package and build it in the Qt
packages, then the Qt package can Obsoletes/Provides WebKit-qt for a smooth
(If all goes well with that, maybe we can push it as part a post-F9 update; but
we'll cross that bridge when we come to it.)
Fwiw, qt's devel (F-10) branch currently includes qt-4.4-rc1, but
1. it's cvs-only atm, not built yet
2. webkit (and phonon) bits are currently disabled
When/if webkit is enabled in qt, one possible migration plan would be to
simply include in qt, Obsoletes/Provides for WebKit-qt and WebKit-qt-devel.
I think we should put the WebKit stuff in a subpackage (of qt). Sure, Plasma is
going to require it as far as I know, but many Qt-only apps and several KDE
apps (which don't need kdebase-workspace) won't.
nod, maybe even be crazy and make the (sub)pkg be named WebKit-qt. :)
Sounds like a plan, then. Thanks for your input! =)
Also, since the standalone WebKit package will then be GTK+ only, we may end up
dropping the -gtk subpackage and making the package as a whole just the GTK+ port.
Peter, it would make sense to ask your WebKit upstream what their thoughts are.
In particular, it's not 100% clear to me what the relationship between WebKit
(here) and qt4's version of it. (And I'll do likewise on the qt-side of things).
from #kde-devel today:
[12:40] <rdieter> possible silly question: what's the relationship between
qt-4.4's WebKit and WebKit's own qt4 bindings? they seem to provide the same
thing (with identical sonames). see also http://bugzilla.redhat.com/442200
[12:43] <hydrogen> rdieter: I believe that qt4.4's webkit is a branch thats been
frozen to be distributed with 4.4
[12:43] * rdieter guessed that
[12:44] <rdieter> thx, I assume the preference should be for distros to ship
qt4.4's WebKit (with KDE-4.1) instead of messing with WebKit's own qt stuff then.
One more goodies:
[12:49] <fredrikh> rdieter: qtwebkit is a fork of the safari-3-branch in WebKit svn
[12:49] <fredrikh> some of the changes have been forward ported to ToT
[12:49] <fredrikh> some haven't, and some have been rejected by apple
Alright, I'm going to build qt-4.4 in devel/F-10 branch, adding
Obsoletes/Provides: WebKit-qt (versioned)
Peter, can you take care of the WebKit-side of things to omit the qt4 bits?
(In reply to comment #7)
> Alright, I'm going to build qt-4.4 in devel/F-10 branch, adding
> Obsoletes/Provides: WebKit-qt (versioned)
> Peter, can you take care of the WebKit-side of things to omit the qt4 bits?
Will do. I'll push a devel/F-10 update with the Qt bits removed.
So with your Obsoletes/Provides in qt-4.4.0-0.6.rc1, any current WebKit-qt users
_should_ automagically find themselves upgrading to the Qt stuff. Thanks!
is this still an active issue or has it been resolved?
Should be all resolved (in Rawhide now, in F9 and F8 once we push Qt 4.4).
If/when you do end up pushing Qt 4.4 to F8/F9, please let me know so I can
adjust the WebKit packages accordingly, as I did for the Rawhide stuff. (Or,
alternatively, feel free to hack those packages out of the spec yourself.)
What's the point of pushing updates for this for F9 and F8? All it does is
remove a subpackage which is obsoleted away anyway. I synced this to F-8 too,
but IMHO it should be removed from the F9 and F8 updates, it's completely
unnecessary churn, the update changes nothing whatsoever for the users of the
subpackages which are not obsoleted, nor for those of the subpackages which
_are_ obsoleted because qt/qt4 replaces them either way.
(For F8, I'll simply not include it in my update push, but IMHO it should be
removed from the F9 updates as well.)
Of course, future WebKit updates need not include the -qt* subpackages, so it's
OK to have this in CVS now, I just think it's completely useless to push this
as an update with no other changes.
Yes and no.
1. If existing WebKit pkgs are in updates, this update will remove the
superfluous -qt subpkg.
2. The new available srpm will rebuild correctly (for users that do that, too
I'll double check 1. if no WebKit is in a particular release's updates repo, I
would agree that it should be omitted from that kde update.
I'll try pinging other fedora rel-eng'ers, they may well agree on the needless
churn, and I would defer to that opinion.
We (KDE maintainers) have decided not to include the WebKit respins in the Qt
4.4 / KDE 4.1 updates. We are leaving the decision to you, the WebKit
maintainer. If you think an update to remove the WebKit-qt* subpackages is
warranted, feel free to submit separate updates with them. For reference, the
relevant builds are WebKit-1.0.0-0.12.svn34655.fc9 for Fedora 9 and
WebKit-1.0.0-0.11.svn34655.fc8 for Fedora 8.
As you've said, updates for merely removing a subpackage that would be Obsoleted
anyway is just unnecessary churn. I'll untag them and let them go into the Koji
trash bin for now.
I'll probably leave the Qt stuff out for future snapshot updates though since
that keeps the spec quite a bit simpler, and Trolltech is handling most of the
upstream WebKit/Qt stuff anyway.