Discussion:
Python 2 Package Removal and when to use fedora-obsolete-packages
Scott Talbert
2018-09-08 01:49:40 UTC
Permalink
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
_______________________________________________
python-devel mailing list -- python-***@lists.fedoraproject.org
To unsubscribe send an email to python-devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/
Zbigniew Jędrzejewski-Szmek
2018-09-08 08:57:01 UTC
Permalink
Post by Scott Talbert
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
_______________________________________________
python-devel mailing list -- python-***@lists.fedoraproject.org
To unsubscribe send an email to python-devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/python-***@lists.fedoraproject.
Miro Hrončok
2018-09-09 18:43:16 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Scott Talbert
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
Post by Zbigniew Jędrzejewski-Szmek
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.
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.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-***@lists.fedoraproject.org
To unsubscribe send an email to python-devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/arc
Scott Talbert
2018-09-10 03:14:57 UTC
Permalink
Post by Zbigniew Jędrzejewski-Szmek
Post by Scott Talbert
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
Post by Zbigniew Jędrzejewski-Szmek
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.
Okay, after thinking about this example, my package _would_ actually have
a problem on upgrade, so thanks for the example.
Post by Zbigniew Jędrzejewski-Szmek
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.
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
Zbigniew Jędrzejewski-Szmek
2018-09-10 08:03:41 UTC
Permalink
Post by Scott Talbert
Post by Miro Hrončok
Post by Zbigniew Jędrzejewski-Szmek
Post by Scott Talbert
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
Post by Scott Talbert
Post by Miro Hrončok
https://pagure.io/packaging-committee/issue/754#comment-512716
Post by Zbigniew Jędrzejewski-Szmek
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.
Okay, after thinking about this example, my package _would_ actually
have a problem on upgrade, so thanks for the example.
Post by Miro Hrončok
Post by Zbigniew Jędrzejewski-Szmek
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.
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
_______________________________________________
python-devel mailing list -- python-***@lists.fedoraproject.org
To unsubscribe send an email to python-devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/python-***@lists.fedo
Jason L Tibbitts III
2018-09-13 18:51:10 UTC
Permalink
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<
_______________________________________________
python-devel mailing list -- python-***@lists.fedoraproject.org
To unsubscribe send an email to python-devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/python-de
Zbigniew Jędrzejewski-Szmek
2018-09-15 16:14:58 UTC
Permalink
Hi,

there's a misunderstanding, so I'll reply to the part of your email
Post by Jason L Tibbitts III
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.".
Post by Jason L Tibbitts III
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.
Post by Jason L Tibbitts III
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.
Post by Jason L Tibbitts III
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.
Post by Jason L Tibbitts III
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 mailing list -- python-***@lists.fedoraproject.org
To unsubscribe send an email to python-devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archi

Loading...