Bug 1443614 - Please obsolete webkitgtk and webkitgtk3
Summary: Please obsolete webkitgtk and webkitgtk3
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-obsolete-packages
Version: rawhide
Hardware: All
OS: All
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-04-19 14:43 UTC by Michael Catanzaro
Modified: 2017-07-14 00:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-07-11 22:14:10 UTC
Type: Bug

Attachments (Terms of Use)

Description Michael Catanzaro 2017-04-19 14:43:12 UTC
Adam Williamson has requested that fedora-obsolete-packages should obsolete the retired webkitgtk and webkitgtk3 packages in rawhide (only rawhide, not F26!). Details:


Comment 1 Jason Tibbitts 2017-05-16 17:47:05 UTC
Somehow I just noticed this bug.  Could you provide information on the versions which need to be obsoleted, and provide the reasons why this package must obsolete them?  I would rather someone who knows tell me instead of me having to follow links and potentially interpret things improperly.

See bug 1451372 for a ticket which tells me what I need to know.

Comment 2 Michael Catanzaro 2017-05-16 18:18:43 UTC
I don't know, Adam?

Comment 3 Adam Williamson 2017-05-16 19:09:28 UTC
It would be nice to do this to ensure the obsolete packages are removed on system upgrade, that's the situation in which I've noted this problem (upgrades of systems with webkitgtk3 installed, which includes some of the default package sets, without --allow-erasing fail because webkitgtk3 is built against an old libicu).

The last webkitgtk build was webkitgtk-2.4.11-5.fc26 and the last webkitgtk3 build was webkitgtk3-2.4.11-5.fc26 . So I'd recommend obsoletes like:

Obsoletes: webkitgtk < 2.4.11-6
Obsoletes: webkitgtk3 < 2.4.11-6

this would require, though, that any future updates for the packages in the stable releases (it's still alive in 25 and 26) be built as 2.4.11-5.1 , 2.4.11-5.2 etc. rather than being built as 2.4.11-6.

Comment 4 Jason Tibbitts 2017-05-16 20:21:17 UTC
OK, thanks for the info.

It's mildly distasteful to have to do sub-release bumps like that.  How often does this package update in the release branches?  Is it possible to simply bump the version obsoleted in this package occasionally, or to simply reserve some releases?

For the latter, I mean using something like "Obsoletes: webkitgtk < 2.4.11-10" and then if the package comes back it just has to start with release 10.  If it's updated frequently, maybe reserve up to 20, but it doesn't look like it updates all that often.  We could document the need to start with a minimum release in the dead.package file of the two packages.

Comment 5 Adam Williamson 2017-05-16 20:54:41 UTC
"It's mildly distasteful to have to do sub-release bumps like that."

Well, I don't really see why. Though I actually got the format slightly wrong, per the policy, it should be 2.4.11-5.fc26.1 , 2.4.11-5.fc26.2 etc. The guidelines explicitly endorse this and refer to it as <minorbump>:


but sure, you could just pick a number, but that seems like a sloppier approach to me; it means if the package ever gets resurrected for any reason, there's a slight possibility the resurrecter might pick the wrong number and build a package that's still obsoleted. It'd be much more likely a resurrection would come with a new *version* number too, of course, in which case it'd be academic, but the possibility exists. And of course you might pick a number that's too low...

Comment 6 Jason Tibbitts 2017-05-16 21:12:44 UTC
Well, yeah, I wrote those guidelines.

It's still mildly distasteful because, well, people get it wrong.  As your example illustrates.  And the owners of the currently maintained branches will definitely have to take care with the release.  I notice only one of the main maintainers of both packages is CC'd here.

In any case, having to do this at all is distasteful.  I'm happy with what works for whoever will continue to maintain the packages in <= F26.

Comment 7 Adam Williamson 2017-05-16 21:20:02 UTC
Ah, heh.

I CCed tpopela so he'd be aware of the bug and could chime in with his preferences/thoughts.

Comment 8 Michael Catanzaro 2017-05-16 21:23:54 UTC
Why do we even want to do this? What is the point in making upgrades succeed without --allow-erasing? Aren't we defeating the entire point of that, which is to make sure users know that packages are going to be erased?

Anyway, more likely than not, there will not be any new builds of these packages again, so the version used in the obsoletes does not matter very much. Both 2.4.11-6 and 2.4.11-10 seem fine to me.

Comment 9 Kevin Fenzi 2017-05-16 21:27:24 UTC
IMHO it would be fine to just 

Obsoletes: webkitgtk < 2.4.12
Obsoletes: webkitgtk3 < 2.4.12

Theres some kind of small chance someone might need to rebuild them (although I sure hope its low), but I can't see another release happening ever. If someone by some miracle revived them somewhere they should likely pick a new name or at the very least make a new version. If this causes some problem down the road, we could adjust the obsoletes, but I doubt it will.

Comment 10 Adam Williamson 2017-05-16 21:28:49 UTC
"Aren't we defeating the entire point of that, which is to make sure users know that packages are going to be erased?"

No, not really. Obsoletes are always respected; you can't expect that no packages will ever be removed on a run without --allow-erasing (or there'd be no *point* to doing this). Passing --allow-erasing is basically telling dnf "I'm OK with you removing as many packages as you need to make this work"; it's fine for a situation like *this*, where the package is actually obsolete and there's no problem with removing it, but you probably don't want it if there's some kind of problem with a package that's *not* obsolete and that you *do* use which dnf can "solve" by removing that package, because you're telling dnf it's fine to go ahead and do that.

In one way this is just good housekeeping; I believe *all* retired packages should be obsoleted by something, rather than leaving them lying around as an unmaintained potential security issue, source of crasher bugs and so on. It seems silly to be to have the strategy for removing retired packages from installed systems be "just wait until one of its dependencies breaks so dnf is forced to remove it".

Comment 11 Adam Williamson 2017-07-11 22:14:10 UTC
Well, I got sick of this and just went ahead and did it:


so this will be fixed by https://koji.fedoraproject.org/koji/taskinfo?taskID=20465736 when it's done.

Comment 12 Lorenzo J. Lucchini 2017-07-14 00:34:15 UTC
I am not sure if this was an intended outcome, but this makes me unable to dnf upgrade or distro-sync on rawhide with Epiphany installed, as it seems to depend on the obsoleted packages:

$ sudo dnf distro-sync
Last metadata expiration check: 0:17:58 ago on Fri 14 Jul 2017 02:15:49 AM CEST.
 Problem: problem with installed package empathy-3.12.13-1.fc27.x86_64
  - package empathy-3.12.13-1.fc27.x86_64 requires libjavascriptcoregtk-3.0.so.0()(64bit), but none of the providers can be installed
  - webkitgtk3-2.4.11-5.fc26.x86_64 does not belong to a distupgrade repository

$ sudo dnf upgrade
Last metadata expiration check: 0:18:12 ago on Fri 14 Jul 2017 02:15:49 AM CEST.
Dependencies resolved.

 Problem: package fedora-obsolete-packages-27-3.noarch obsoletes webkitgtk3 < 2.4.12 provided by webkitgtk3-2.4.11-5.fc26.x86_64
  - package empathy-3.12.13-1.fc27.x86_64 requires libjavascriptcoregtk-3.0.so.0()(64bit), but none of the providers can be installed
  - cannot install the best update candidate for package webkitgtk3-2.4.11-5.fc26.x86_64
  - cannot install the best update candidate for package empathy-3.12.13-1.fc27.x86_64
Nothing to do.

Comment 13 Adam Williamson 2017-07-14 00:51:48 UTC
Well, webkitgtk3 was certainly intentionally retired, and does not appear in current Rawhide composes:


note there's no webkitgtk3 there. So, I'd say the problem is that empathy (note: empathy, not epiphany) needs rebasing to a supported webkitgtk (i.e. 4).

Comment 14 Adam Williamson 2017-07-14 00:56:17 UTC
See: https://bugzilla.redhat.com/show_bug.cgi?id=1375835

Note You need to log in before you can comment on or make changes to this bug.