#645 Clarify policy on obsoleting non-directly-replaced packages
Closed: Fixed None Opened 5 years ago by adamwill.

The packaging guidelines explain in quite a lot of detail how to handle the case where a package is directly replaced (so use of Obsoletes: and Provides:) -


However, neither page really specifies any policy on what should be done with packages which are not directly replaced. For instance, if they are being retired simply for lack of maintainer interest, or if the functionality of the package is being replaced somehow, but not in such a way that there's a clear candidate for Provides:.

This is a problem especially when doing upgrades. Quite often a retired package's dependencies will no longer be satisfied - this is pretty natural, since it's retired, it doesn't get rebuilt for soname bumps and so on.

If the package is not explicitly obsoleted by anything, package tools cannot just assume it's OK to remove the package, so they usually just bail with an error in this situation, and require some kind of explicit instruction that it's OK to remove the package.

We've talked around this problem a few times in the past but never really done anything about it, I'm not sure there's ever been a formal consideration of it, though.

There's a significant case of this outstanding right now: https://bugzilla.redhat.com/show_bug.cgi?id=1366793 - the 'dnf-langpacks' package was retired because a different implementation of langpacks superseded the dnf-langpacks implementation. However, at present nothing obsoletes dnf-langpacks, and its dependencies are no longer available on Fedora 25 and Rawhide. This means that most upgrades from Fedora 23 to Fedora 25 or Rawhide will fail due to dnf-langpacks dependencies not being satisfied, requiring the user to remove it manually before upgrading or pass --allowerasing to dnf.

There isn't a clear-cut 'successor package' to dnf-langpacks which can Obsoletes: and Provides: it, since the new implementation is done rather differently. There also isn't an obvious candidate for a package to just Obsoletes: it either - it would need to be a package which we could rely on being installed on all systems where dnf-langpacks is installed; I suggested 'dnf', and I think that's probably a viable choice, but with the lack of any guidelines it's actually pretty difficult to decide whether doing this is 'the right thing' or not.

A related question here is, do we want to 'fix' this with packaging policies such that the packages always handle things and we don't need any changes to the package management tools, or do we want to ask the package management tools to change in some way.

One possibility we've floated before is a special metapackage whose sole job is to Obsoletes: retired packages, and which would be effectively a mandatory package which would always be installed...

I don't think this is really in FPC's domain. To be honest it seems like something the update agents are simply going to have to figure out how to handle. It's a perfectly valid case that things will go away and nothing will obsolete them. From a packaging standpoint, I'd think that the best way to handle any particular scenario would depend entirely on the details of that scenario, and we certainly can't write up guidelines to cover every case.

So what are you looking for from FPC here? There's already a blanket statement about handling exceptional cases. If you are asking us if it's OK for some package to obsolete things which it doesn't strictly provide because of an exceptional case, then that would be covered by the existing policy.

Otherwise, honestly, I don't really know what a guideline would say, and you don't make a specific proposal for language we would use, so it's kind of tough.

On your related question, that is entirely in the realm of FESCo. FPC isn't going to say one way or another what the update agents should do in any particular case. If FESCo decides what it would like to do in these situations and asks FPC to codify the packaging-related part into guidelines then of course FPC would do that.

And I actually proposed the special metapackage years ago and was shot down pretty strongly.

I'm pretty sure that if we would have metapackages instead of comps, then we just add Obsoletes to appropriate package. Actually this is how it works in Maria.

Replying to [ticket:645 adamwill]:

a different implementation of langpacks superseded the dnf-langpacks implementation.
There isn't a clear-cut 'successor package' to dnf-langpacks

The superseding implementation isn't the clear-cut successor?

I mean, does it matter that the implementation is different? Are there any concrete problems that would be caused by the addition of the Provides in this case? If not, you should just add it and drop the provides in a few releases when it is safe to do so. (The guidelines you quoted say when it is safe to do so.)

Replying to [comment:3 ignatenkobrain]:

I'm pretty sure that if we would have metapackages instead of comps, then we just add Obsoletes to appropriate package. Actually this is how it works in Maria.

You want to do it that way so it doesn't work if people didn't install via. groups?

If you want to have a dedicated package to do obsoletes, you just need someone to volunteer to monitor the packages that disappear and put the obsoletes into something that is installed. I argued fedora-release should do it a long time ago, but they didn't want to overload it's usage. shrug.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-08-18/fpc.2016-08-18-16.01.txt):

  • 645 Clarify policy on obsoleting non-directly-replaced packages

    (geppetto, 16:14:57)
  • ACTION: Can you write a concrete proposal, that we could vote on, so
    we aren't discussing trying to solve the wrong problem. (geppetto,

I'll drop this to needinfo. But basically it's down to us wondering how the guidelines could change in any way which makes this situation better.

The dnf-langpacks situation appears to be covered already, so it probably isn't that. Is it that you'd like for us to say what a packager should do when a package is going away and nothing obsoletes it? If so, that's kind of an odd case because the package will be gone so the guidelines would really apply in any case. Seems that's a technical or release engineering issue that FESCo or someone else would need to solve.


No, the dnf-langpacks issue is not 'covered already'. We have an idea for what we can do, but we have no idea if that would be the 'best' solution, or if it's in line with what any other similar case chose to do. Which is what guidelines are for, right? Which is why we'd like some.

"Is it that you'd like for us to say what a packager should do when a package is going away and nothing obsoletes it?"

Well, not quite. I'd like you to say what a packager should do when a package is going away and there is no clear direct replacement. Should they just do nothing, i.e. have nothing obsolete it? Should they try to find a package which can sufficiently Obsoletes: it (i.e. one they can rely on being installed on every system which would have had the being-retired package installed)? Should they have a special metapackage which we invent obsolete it? Is there another choice?

mbooth: the issue in the dnf-langpacks case is that the new implementation doesn't have a direct replacement for the dnf-langpacks binary package:


so there is no obvious candidate for a single package that should Obsoletes: and Provides: dnf-langpacks (i.e. there's no single package which should be installed as a direct replacement for dnf-langpacks on every system which has that package installed).

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-08-25/fpc.2016-08-25-16.00.txt):

  • 645 Clarify policy on obsoleting non-directly-replaced packages

    (geppetto, 17:03:45)
  • LINK:
    (tibbs, 17:08:45)
  • ACTION: Rathann talks to fesco about it (geppetto, 17:24:15)
  • Obvious possabilities are: "obsoleted-packages" package; metadata
    from pkgdb; use "yum list distro-extras" logic. (geppetto,

So what is the state here after FeSCo ruling [1]. I am asking since Ruby upstream apparently unbundled Tcl/Tk support from Ruby and there is no ideal place to obsolete ruby-tcltk package (I'm going to do that in ruby-libs, but that is not the right place IMO).

[1] https://fedorahosted.org/fesco/ticket/1620

Well, FESCo says handle on a case-by-case basis. I'm going to guess that they're simply leaving it up to us to provide various methods.

So step one from our point, I think, is to list out all of the reasonable options a maintainer can follow when a package goes a way. Here's a start:

  1. Have some related package obsolete the removed one.
  2. Add the package to the distro wide "fedora-obsolete-packages" package.
  3. Simply leave the package in place and leave it to the update tools.

For the latter, well, I don't think the update tools handle it at all, though they will bail on dependency issues and I would hope that they could get smarter about at least telling the user what to do.

For the former, that's going to be up to the maintainer.

For the other, I will go ahead and submit a package for review, and then let others figure out whether to install it by default or something. The dnf system-upgrade plugin could depend upon it, perhaps.

I think it's worth considering whether adding things to fedora-obsolete-packages should be gated through FPC.

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2016-09-15/fpc.2016-09-15-16.01.txt):

  • 645 Clarify policy on obsoleting non-directly-replaced packages

    (geppetto, 16:30:09)
  • LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1376149 (tibbs,
  • ACTION: tibbs Write up policy change for obsolting package
    fedora-obsolete-packages (+1:5, 0:0, -1:0) (geppetto, 16:49:39)

I find it extremely user-unfriendly to automatically remove packages that may still be working and that explicitly have no replacement and make it painful to reinstall them.

So you appear to be in agreement with FPC's proposals so far. That's good.

The package exists and is built in rawhide. I wrote a small bit into the guidelines to explain how to get obsoletes added.

Announcement text:

The guidelines for replacing existing packages have been updated with mention of the "fedora-obsolete-packages" package:

Metadata Update from @tibbs:
- Issue assigned to tibbs

5 years ago

Login to comment on this ticket.