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 upgrade path. (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.) Thanks.
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) (somewhere). 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) > (somewhere). > > 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.) Thanks. :D
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 many, imo). 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. Thanks!