I'm thinking about removing some of my Python 2 subpackages (that are no longer used). However, I'm wondering about the case where the removed packages should be added to fedora-obsolete-packages. I don't _think_ the removal of my packages would cause any problems upon upgrade.
Can someone provide an example of a situation where a removed package could cause a problem on upgrade (and should thus be added to fedora-obsolete-packages).
Thanks, Scott
On Fri, Sep 07, 2018 at 09:49:40PM -0400, Scott Talbert wrote:
I'm thinking about removing some of my Python 2 subpackages (that are no longer used). However, I'm wondering about the case where the removed packages should be added to fedora-obsolete-packages. I don't _think_ the removal of my packages would cause any problems upon upgrade.
Can someone provide an example of a situation where a removed package could cause a problem on upgrade (and should thus be added to fedora-obsolete-packages).
Hi,
you should always add the old subpackage to fedora-obsolete-packages.
There are two possibilities for how the subpackage affects upgrade: 1. if your subpackage depends on other packages, then the presence of your subpackage can prevent the upgrade of those other packages. Users might need to use --allowerasing to work around that, and we don't want that, upgrades must be possible without --allowerasing.
2. if your subpackage does not depend on anything except python2, then there is no immediate problem with upgrade (since python2 is staying around for now), but the users of your package have an obsolete package installed that is not being upgraded or supported.
Note that policy is that python2- subpackages should be removed before the release of any given Fedora version, the same as for normal packages.
Zbyszek
On 8.9.2018 10:57, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Sep 07, 2018 at 09:49:40PM -0400, Scott Talbert wrote:
I'm thinking about removing some of my Python 2 subpackages (that are no longer used). However, I'm wondering about the case where the removed packages should be added to fedora-obsolete-packages. I don't _think_ the removal of my packages would cause any problems upon upgrade.
Can someone provide an example of a situation where a removed package could cause a problem on upgrade (and should thus be added to fedora-obsolete-packages).
Hi,
you should always add the old subpackage to fedora-obsolete-packages.
This is not the FPC's conclusion. You should only do it if it is problematic (as in your example 1 bellow).
https://pagure.io/packaging-committee/issue/754#comment-512716
There are two possibilities for how the subpackage affects upgrade:
if your subpackage depends on other packages, then the presence of your subpackage can prevent the upgrade of those other packages. Users might need to use --allowerasing to work around that, and we don't want that, upgrades must be possible without --allowerasing.
if your subpackage does not depend on anything except python2, then there is no immediate problem with upgrade (since python2 is staying around for now), but the users of your package have an obsolete package installed that is not being upgraded or supported.
A shared subpackage example:
python2-foo requires python-foo-common = %{version}-%{release} python3-foo requires python-foo-common = %{version}-%{release}
When python2-foo is removed from repos but remains on installed system and the python3 version is updated, the user will get an error upon regular dnf upgrade.
A third party libray example:
python2-pdf-hoovercraft requires libpoppler.so.78()(64bit)
When python2-foo is removed from repos but remains on installed system and the libpoppler soname version is updated, the user will get an error upon regular dnf upgrade.
On Sun, 9 Sep 2018, Miro Hrončok wrote:
I'm thinking about removing some of my Python 2 subpackages (that are no longer used). However, I'm wondering about the case where the removed packages should be added to fedora-obsolete-packages. I don't _think_ the removal of my packages would cause any problems upon upgrade.
Can someone provide an example of a situation where a removed package could cause a problem on upgrade (and should thus be added to fedora-obsolete-packages).
Hi,
you should always add the old subpackage to fedora-obsolete-packages.
This is not the FPC's conclusion. You should only do it if it is problematic (as in your example 1 bellow).
https://pagure.io/packaging-committee/issue/754#comment-512716
There are two possibilities for how the subpackage affects upgrade:
- if your subpackage depends on other packages, then the presence of your subpackage can prevent the upgrade of those other packages. Users might need to use --allowerasing to work around that, and we don't want that, upgrades must be possible without --allowerasing.
Okay, after thinking about this example, my package _would_ actually have a problem on upgrade, so thanks for the example.
- if your subpackage does not depend on anything except python2, then there is no immediate problem with upgrade (since python2 is staying around for now), but the users of your package have an obsolete package installed that is not being upgraded or supported.
Actually, I think Zbyszek may be right that we need to worry about this case. Say there is a python2 package that only depends on python(abi) = 2.7 and this package is stopped from building. This package will remain on user's systems. Then in Fedora 58, Python 2 is finally removed. If the Python 2 packages are obsoleted, won't this cause a problem with the original Python 2 subpackage?
Scott
On Sun, Sep 09, 2018 at 11:14:57PM -0400, Scott Talbert wrote:
On Sun, 9 Sep 2018, Miro Hrončok wrote:
I'm thinking about removing some of my Python 2 subpackages (that are no longer used). However, I'm wondering about the case where the removed packages should be added to fedora-obsolete-packages. I don't _think_ the removal of my packages would cause any problems upon upgrade.
Can someone provide an example of a situation where a removed package could cause a problem on upgrade (and should thus be added to fedora-obsolete-packages).
Hi,
you should always add the old subpackage to fedora-obsolete-packages.
This is not the FPC's conclusion. You should only do it if it is problematic (as in your example 1 bellow).
Heh, I don't think the FPC policy is very robust. We know from experience that when users see "80 packages cannot be upgraded and were skipped", they don't like it. I'm myself an experienced packager and I still hate it, because it takes quite a bit of time to figure out what exactly is the issue. Sometimes it's indeed an obsolete package, but sometimes maintainers screw up and there's a conflict between packages, sometimes it's a mirror issue [1].
With the policy of "obsolete from fedora-obsolete-packages sometimes" we'll always be playing whack-a-mole because with approx. 2800 subpackages becoming obsolete, it is absolutely guaranteed that some maintainers get it wrong. There's even 700+ non-noarch packages which are much more likely to cause problems.
IMHO a simple policy of "always obsolete" is the only thing that can work at this scale.
[1] https://pagure.io/releng/issue/7792
https://pagure.io/packaging-committee/issue/754#comment-512716
There are two possibilities for how the subpackage affects upgrade:
- if your subpackage depends on other packages, then the presence of your subpackage can prevent the upgrade of those other packages. Users might need to use --allowerasing to work around that, and we don't want that, upgrades must be possible without --allowerasing.
Okay, after thinking about this example, my package _would_ actually have a problem on upgrade, so thanks for the example.
- if your subpackage does not depend on anything except python2, then there is no immediate problem with upgrade (since python2 is staying around for now), but the users of your package have an obsolete package installed that is not being upgraded or supported.
Actually, I think Zbyszek may be right that we need to worry about this case. Say there is a python2 package that only depends on python(abi) = 2.7 and this package is stopped from building. This package will remain on user's systems. Then in Fedora 58, Python 2 is finally removed. If the Python 2 packages are obsoleted, won't this cause a problem with the original Python 2 subpackage?
Yes, it will. Users will get a message from 'dnf upgrade' like "450 packages were not upgraded" (with a long list including python2 and the offending python2 subpackages). If users switch to "--best --allowerasing", the upgrade will go through, but at this scale users will not be able to tell if they are removing just obsolete packages or if in this list there are interspersed packages that they care about.
Zbyszek
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> Heh, I don't think the FPC policy is very robust.
It's as robust as is reasonable to implement.
When fedora-obsolete-packages was introduced, there was considerable controversy over whether it is remotely acceptable to remove installed packages from end user systems when those packages aren't causing actual problems for anyone. The decision was made that they would be removed only when they cause dependency issues, and that this would be limited as much as possible to updates between Fedora releases.
So, that's fedora-obsolete-packages. If you think it should be changed, feel free to bring it before FESCo and go through the discussion again. Personally I agree with the original decision: We should not simply be yanking software off of someone's system unless we simply have to do so because the system cannot be updated otherwise.
ZJ> We know from experience that when users see "80 packages cannot be ZJ> upgraded and were skipped", they don't like it.
Unless they are relying on those packages for something, of course. If you've figured out how to tell that's the case, feel free to give details. I would rather have an occasional message whenever possible rather than breaking someone's setup, but that's just me.
ZJ> With the policy of "obsolete from fedora-obsolete-packages ZJ> sometimes" we'll always be playing whack-a-mole because with ZJ> approx. 2800 subpackages becoming obsolete, it is absolutely ZJ> guaranteed that some maintainers get it wrong.
I would think that centralizing the obsoletes would make things better, not worse. It's certainly better than "obsolete from some other random package". And if we _know_ that there will be dependency problems (such as the old python2 package itself having to be obsoleted) then there isn't much of a question here, is there? The obsoletes would need to be added.
ZJ> IMHO a simple policy of "always obsolete" is the only thing that can ZJ> work at this scale.
What scale are you talking about? It's not clear to me if you're disagreeing with the entire concept of the distribution being conservative about removing packages from end-user systems, or if you have an argument that all python2 packages will need to be obsoleted regardless. If that's the case, then talking about the robustness of the policy seems odd because you're not actually disagreeing with it. You should instead simply make your argument so we can get on with business.
- J<
Hi,
there's a misunderstanding, so I'll reply to the part of your email where I think we're in mostly in agreement first:
On Thu, Sep 13, 2018 at 01:51:10PM -0500, Jason L Tibbitts III wrote:
"ZJ" == Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl writes:
ZJ> With the policy of "obsolete from fedora-obsolete-packages ZJ> sometimes" we'll always be playing whack-a-mole because with ZJ> approx. 2800 subpackages becoming obsolete, it is absolutely ZJ> guaranteed that some maintainers get it wrong.
I would think that centralizing the obsoletes would make things better, not worse. It's certainly better than "obsolete from some other random package". And if we _know_ that there will be dependency problems (such as the old python2 package itself having to be obsoleted) then there isn't much of a question here, is there? The obsoletes would need to be added.
Yes, I think obsoleting from fedora-obsolete-packages is perfectly OK. My beef was with obsoleting being optional. I'd like the policy to be "python2- subpackage SHOULD be obsoleted from fedora-obsolete-packages.".
ZJ> IMHO a simple policy of "always obsolete" is the only thing that can ZJ> work at this scale.
What scale are you talking about? It's not clear to me if you're disagreeing with the entire concept of the distribution being conservative about removing packages from end-user systems, or if you have an argument that all python2 packages will need to be obsoleted regardless. If that's the case, then talking about the robustness of the policy seems odd because you're not actually disagreeing with it. You should instead simply make your argument so we can get on with business.
I'm disagreeing with the part of the policy that makes obsoleting conditional on some unspecified future problems. I'm convinced that this is not robust in the sense that not-obsoleted package will to many small problems for users during upgrades.
ZJ> Heh, I don't think the FPC policy is very robust.
It's as robust as is reasonable to implement.
When fedora-obsolete-packages was introduced, there was considerable controversy over whether it is remotely acceptable to remove installed packages from end user systems when those packages aren't causing actual problems for anyone. The decision was made that they would be removed only when they cause dependency issues, and that this would be limited as much as possible to updates between Fedora releases.
Ack. "between releases" is important.
So, that's fedora-obsolete-packages. If you think it should be changed, feel free to bring it before FESCo and go through the discussion again. Personally I agree with the original decision: We should not simply be yanking software off of someone's system unless we simply have to do so because the system cannot be updated otherwise.
I understand the motivations for the policy, but to me the assumptions about the effect of various choices that guided the creation of that policy are not entirely valid anymore.
The primary now-invalid assumption is that users can a) tell which packages have been abandoned by the distribution, b) make a choice whether to keep them or not.
I'm pretty sure that with gnome-software (or any other graphical updater) all the user can say is "some packages are not being updated". With dnf, it's a bit better, but still pretty hard to figure out.
ZJ> We know from experience that when users see "80 packages cannot be ZJ> upgraded and were skipped", they don't like it.
Unless they are relying on those packages for something, of course. If you've figured out how to tell that's the case, feel free to give details. I would rather have an occasional message whenever possible rather than breaking someone's setup, but that's just me.
As I wrote before, and I don't think anybody disagrees, users learn about abandoned packages only when the package managers tells them that some *other* packages cannot be upgraded. It is not obvious which of the huge set of packages that dnf lists is the "real offender".
Instead, when we obsolete packages from fedora-obsolete-packages, the message is clearer: "Removing python-foo, obsoleted by fedora-obsolete-packages". A power user can do 'dnf --exclude python-foo' and keep the old package if they wish. Normal users just get the package removed. This would only happen during Fedora version upgrades, where users are faces with changes anyway and learn to adapt to them.
To summarize, I'd rather have users see "Removing python2-foo, python2-bar, obsoleted by fedora-obsolete-packages", then "Cannot update python2-xxx, no candidate for install", and to achieve this, I think the policy should be to add all those python2- packages to fedora-obsolete-packages.
Zbyszek
python-devel@lists.fedoraproject.org
-
Jason L Tibbitts III -
Miro Hrončok -
Scott Talbert -
Zbigniew Jędrzejewski-Szmek