I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
Barry
On Sun, 10 May 2020, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedor...
I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now.
Scott
On 10. 05. 20 18:37, Scott Talbert wrote:
On Sun, 10 May 2020, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedor...
I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now.
You should still be able to exclude the package in the dnf config:
$ cat /etc/dnf/dnf.conf [main] ... exclude=fedora-obsolete-packages
On Sun, May 10, 2020 at 08:20:52PM +0200, Miro Hrončok wrote:
On 10. 05. 20 18:37, Scott Talbert wrote:
On Sun, 10 May 2020, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedor...
I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now.
You should still be able to exclude the package in the dnf config:
$ cat /etc/dnf/dnf.conf [main] ... exclude=fedora-obsolete-packages
We really should have made this better announced/documented.
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
:(
Oh well, can we at least common bugs it?
kevin
On Sun, May 10, 2020 at 8:49 PM Kevin Fenzi kevin@scrye.com wrote:
On Sun, May 10, 2020 at 08:20:52PM +0200, Miro Hrončok wrote:
On 10. 05. 20 18:37, Scott Talbert wrote:
On Sun, 10 May 2020, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedor...
I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now.
You should still be able to exclude the package in the dnf config:
$ cat /etc/dnf/dnf.conf [main] ... exclude=fedora-obsolete-packages
We really should have made this better announced/documented.
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
Huh? I don't think how fedora-obsolete-packages works, at least not for a while ... I have never manually installed fedora-obsolete-packages, it was only ever automatically pulled in and installed because it "Obsoletes: something-I-had-installed" before a system upgrade.
Fabio
:(
Oh well, can we at least common bugs it?
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Sun, May 10, 2020 at 09:30:26PM +0200, Fabio Valentini wrote:
On Sun, May 10, 2020 at 8:49 PM Kevin Fenzi kevin@scrye.com wrote:
On Sun, May 10, 2020 at 08:20:52PM +0200, Miro Hrončok wrote:
On 10. 05. 20 18:37, Scott Talbert wrote:
On Sun, 10 May 2020, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
Probably fedora-obsolete-packages: https://src.fedoraproject.org/rpms/fedora-obsolete-packages/blob/f32/f/fedor...
I don't know how to workaround it though as the f-o-p package doesn't actually get installed anymore - it's work happens through some dnf tricks now.
You should still be able to exclude the package in the dnf config:
$ cat /etc/dnf/dnf.conf [main] ... exclude=fedora-obsolete-packages
We really should have made this better announced/documented.
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
Huh? I don't think how fedora-obsolete-packages works, at least not for a while ... I have never manually installed fedora-obsolete-packages, it was only ever automatically pulled in and installed because it "Obsoletes: something-I-had-installed" before a system upgrade.
Yeah, it wasn't necessary to request f-o-p explictly. Packages that were added to f-o-p in the past were added when they broke upgrades. So without f-o-p, the upgrade wouldn't go through because of broken deps, and dnf would pull in f-o-p automatically to make the transaction viable.
We now add some packages more proactively, even when they don't block an upgrade, but f-o-p is still used for many packages that would block an upgrade and f-o-p would still be required to satisfy deps for any fedora-version upgrade and would still be pulled in. So the magic trick that makes f-o-p non-installable doesn't change much.
Zbyszek
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
Is this ideal? No. But it has not been changed. (The changed part is fedora-obsolete-packages does not get installed in the process.)
A better solution to the problem fedora-obsolete-packages is trying to solve would be to use allowerasing on system-upgrade, but that is another can of worms, because it also removes packages that have broken dependencies, but were not intentionally removed.
The idea solution IMHO would be to allow erasing only the packages that do not belong to a distupgrade repository. Possibly to have that option only for the Fedora repos, so packages installed from a thrid-party would not get erased.
On Mon, May 11, 2020 at 01:47:32AM +0200, Miro Hrončok wrote:
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
Is this ideal? No. But it has not been changed. (The changed part is fedora-obsolete-packages does not get installed in the process.)
A better solution to the problem fedora-obsolete-packages is trying to solve would be to use allowerasing on system-upgrade, but that is another can of worms, because it also removes packages that have broken dependencies, but were not intentionally removed.
I think you mean "different", not "better" here ;)
The idea solution IMHO would be to allow erasing only the packages that do not belong to a distupgrade repository. Possibly to have that option only for the Fedora repos, so packages installed from a thrid-party would not get erased.
I don't think that is a good solution either. The problem is that one guy's leftover package is part of another gal's important application stack.
Instead of trying to divine whether a package is important based on source metadata, IMHO it would be better to make the user interface stronger: have dnf say what is removed and why (when obsoleted), and when packages block the upgrade path, offer an option to autoremove *a specific package*. (Right now, the user has to first remove some package by 'dnf remove', and then they can re-run the upgrade, to see if that resolved the issues. There is no guarantee that the removal of the package they removed actually is enough to upgrade successfully.)
I'd imagine the following workflow: $ dnf upgrade --releasever=33 ... list of conflicts ... Try --allow-erasing=foo to remove foo on conflicts $ dnf upgrade --releasever=33 --allow-erasing=foo (here dnf would try the upgrade with considering of foo removal) ...
The advantage is that the user has a change to think whether foo is something that they can do without, or alternatively just write it down on the list of packages to reinstall after update.
Maybe even the following would work: $ dnf upgrade --releasever=33 --allow-erasing='*.fc28.*' (consider removal of any very old package...)
Zbyszek
On 11. 05. 20 9:43, Zbigniew Jędrzejewski-Szmek wrote:
The idea solution IMHO would be to allow erasing only the packages that do not belong to a distupgrade repository. Possibly to have that option only for the Fedora repos, so packages installed from a thrid-party would not get erased.
I don't think that is a good solution either. The problem is that one guy's leftover package is part of another gal's important application stack.
Currently, we manually obsolete all the dropped packages that "are problematic during upgrades". The solution I proposed does the same, sans human heuristics based on incomplete data.
I don't agree that manually asking the user to specify the list of packages to autoremove is better UX. The user is prompted with a transaction summary. If they see part of their important application stack going away, they need to abort and figure out what to do. There is no "simply not remove this" option during upgrade.
Dne 11. 05. 20 v 9:43 Zbigniew Jędrzejewski-Szmek napsal(a):
, IMHO it would be better to make the user interface stronger: have dnf say what is removed and why (when obsoleted)
+1 But we should realize that DNF actually does not have user interface. IMHO this should be only exposed using libdnf and it should be revealed in dnf-dragora, gnome-software and other tools based on top of DNF.
On Mon, May 11, 2020 at 01:47:32AM +0200, Miro Hrončok wrote:
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
ok. Fair enough, I misunderstood how this package worked.
That perhaps explains why I didn't see more people asking for it to be installed by default. :)
Is this ideal? No. But it has not been changed. (The changed part is fedora-obsolete-packages does not get installed in the process.)
A better solution to the problem fedora-obsolete-packages is trying to solve would be to use allowerasing on system-upgrade, but that is another can of worms, because it also removes packages that have broken dependencies, but were not intentionally removed.
Well, that doesn't handle all the use cases either. Really we need to know from the user if thats ok or not. Some users (as is evidenced by this thread) want to keep their obsolete packages.
The idea solution IMHO would be to allow erasing only the packages that do not belong to a distupgrade repository. Possibly to have that option only for the Fedora repos, so packages installed from a thrid-party would not get erased.
I don't think that would be ideal either.
I think we would need to ask the user and explain... but it gets really complex to figure out why some things would need removed.
Anyhow, I will drop this thread myself now, if we see a lot of people complaining about the present behavior we can revist this, but seems most people are fine with obsoleted packages just getting removed on upgrades.
kevin
On Mon, 2020-05-11 at 01:47 +0200, Miro Hrončok wrote:
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
Uh. Are we *sure* about that? Same as Kevin, that is not how I recall this working.
I've long worked under the belief that this if Y Obsoletes: X, but you don't have Y installed (and nothing else in the update would cause it to be pulled in), running 'dnf update' with a repo that contains Y enabled is not going to install Y and remove X. X will stay there. Obsoletes: only kick in if the package that does the obsoleting is installed, or is included in the transaction.
This is - AIUI - why the packaging guidelines say, when you rename a package, that the new package should Obsoletes: *and Provides:* the old package: without the Provides:, you cannot expect the new package to reliably replace the old one.
Are you *sure* that DNF doesn't behave this way? The idea surprises me.
On 12. 05. 20 0:32, Adam Williamson wrote:
On Mon, 2020-05-11 at 01:47 +0200, Miro Hrončok wrote:
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
Uh. Are we *sure* about that? Same as Kevin, that is not how I recall this working.
Yes, I am *sure*.
I've long worked under the belief that this if Y Obsoletes: X, but you don't have Y installed (and nothing else in the update would cause it to be pulled in), running 'dnf update' with a repo that contains Y enabled is not going to install Y and remove X. X will stay there. Obsoletes: only kick in if the package that does the obsoleting is installed, or is included in the transaction.
Package Y that obsoletes X kicks in when you have X installed and Y available. (Assuming both are non-modular. With modules, this concept is broken.)
This is - AIUI - why the packaging guidelines say, when you rename a package, that the new package should Obsoletes: *and Provides:* the old package: without the Provides:, you cannot expect the new package to reliably replace the old one.
The provides is there only to not break existing packages and users who depend on and/or install the old name.
Are you *sure* that DNF doesn't behave this way? The idea surprises me.
Yes, I am *sure*. I guess it's not dnf, but libsolv, hence GNOME Software should behave the same.
Fedora 32 Copr demo:
https://copr.fedorainfracloud.org/coprs/churchyard/obsoleter/
$ sudo dnf copr enable churchyard/obsoleter ...
$ repoquery --repo=copr:copr.fedorainfracloud.org:churchyard:obsoleter --obsoletes obsoleter thunderbird
$ repoquery --repo=copr:copr.fedorainfracloud.org:churchyard:obsoleter --provides obsoleter obsoleter = 0-0
$ sudo dnf --repo=copr:copr.fedorainfracloud.org:churchyard:obsoleter upgrade Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing dependencies: obsoleter noarch 0-0 copr:copr.fedorainfracloud.org:churchyard:obsoleter 6.3 k replacing thunderbird.x86_64 68.7.0-1.fc32
Transaction Summary ================================================================================ Install 1 Package
Total download size: 6.3 k
On Mon, May 11, 2020 at 7:23 PM Miro Hrončok mhroncok@redhat.com wrote:
On 12. 05. 20 0:32, Adam Williamson wrote:
On Mon, 2020-05-11 at 01:47 +0200, Miro Hrončok wrote:
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
Uh. Are we *sure* about that? Same as Kevin, that is not how I recall this working.
Yes, I am *sure*.
I've long worked under the belief that this if Y Obsoletes: X, but you don't have Y installed (and nothing else in the update would cause it to be pulled in), running 'dnf update' with a repo that contains Y enabled is not going to install Y and remove X. X will stay there. Obsoletes: only kick in if the package that does the obsoleting is installed, or is included in the transaction.
Package Y that obsoletes X kicks in when you have X installed and Y available. (Assuming both are non-modular. With modules, this concept is broken.)
This is - AIUI - why the packaging guidelines say, when you rename a package, that the new package should Obsoletes: *and Provides:* the old package: without the Provides:, you cannot expect the new package to reliably replace the old one.
The provides is there only to not break existing packages and users who depend on and/or install the old name.
Are you *sure* that DNF doesn't behave this way? The idea surprises me.
Yes, I am *sure*. I guess it's not dnf, but libsolv, hence GNOME Software should behave the same.
To be clear: Obsoletes affects _only_ upgrades. Our policy says to do Obsoletes+Provides so that when people do *installs*, they get the new package too. fedora-obsolete-packages *explicitly* does not do Provides for this reason.
There were a few YUM hacks where it processed Obsoletes on installs in specific circumstances as well, but that behavior has been gone from Fedora since we switched to DNF in Fedora 22. And good riddance.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, 2020-05-11 at 22:41 -0400, Neal Gompa wrote:
On Mon, May 11, 2020 at 7:23 PM Miro Hrončok mhroncok@redhat.com wrote:
On 12. 05. 20 0:32, Adam Williamson wrote:
On Mon, 2020-05-11 at 01:47 +0200, Miro Hrončok wrote:
On 10. 05. 20 20:48, Kevin Fenzi wrote:
Basically we are switching from 'I go and install fedora-obsolete-packages and have opted in to it' to 'I have to go explictly exclude it to keep my obsolete packges'.
As others have pointed out, this was never the case of 'I go and install fedora-obsolete-packages and have opted in to it' -- this was always the case of 'fedora-obsolete-packages obsoletes something I had installed, so it is pulled in by dep resolver'.
Uh. Are we *sure* about that? Same as Kevin, that is not how I recall this working.
Yes, I am *sure*.
I've long worked under the belief that this if Y Obsoletes: X, but you don't have Y installed (and nothing else in the update would cause it to be pulled in), running 'dnf update' with a repo that contains Y enabled is not going to install Y and remove X. X will stay there. Obsoletes: only kick in if the package that does the obsoleting is installed, or is included in the transaction.
Package Y that obsoletes X kicks in when you have X installed and Y available. (Assuming both are non-modular. With modules, this concept is broken.)
This is - AIUI - why the packaging guidelines say, when you rename a package, that the new package should Obsoletes: *and Provides:* the old package: without the Provides:, you cannot expect the new package to reliably replace the old one.
The provides is there only to not break existing packages and users who depend on and/or install the old name.
Are you *sure* that DNF doesn't behave this way? The idea surprises me.
Yes, I am *sure*. I guess it's not dnf, but libsolv, hence GNOME Software should behave the same.
To be clear: Obsoletes affects _only_ upgrades. Our policy says to do Obsoletes+Provides so that when people do *installs*, they get the new package too. fedora-obsolete-packages *explicitly* does not do Provides for this reason.
There were a few YUM hacks where it processed Obsoletes on installs in specific circumstances as well, but that behavior has been gone from Fedora since we switched to DNF in Fedora 22. And good riddance.
This is not true entirely, DNF also follows obsoletes for install command.
For example, berusky has Obsoletes: berusky-data, but does not have Provides for that. If you try `dnf install berusky-data`, it will install berusky.
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On Sun, May 10, 2020 at 12:32 PM Barry Scott barry@barrys-emacs.org wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
fedora-obsolete-packages is going to keep doing that. There are two options for you:
* Package moin2 and switch to that: https://github.com/moinwiki/moin * Rebuild those packages and bump the release number so that they don't get obsoleted automatically
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Sun, 2020-05-10 at 17:31 +0100, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
fedora-obsolete-packages I guess.
Just build the packages you need with newer version/release. Then python3 subpackage or fedora-obsolete-packages won't remove them.
Barry _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- Igor Raits ignatenkobrain@fedoraproject.org
On 10 May 2020, at 17:45, Igor Raits ignatenkobrain@fedoraproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Sun, 2020-05-10 at 17:31 +0100, Barry Scott wrote:
I know that python2 is a dead language, but I have a need to use some python 2 code on one of my servers. It's clearly on me to maintain the old code if I choose to use it.
I use MoinMoin via mon_wsgi.
After upgrading to fedora 32 I took the trouble to install moin using the F31 package. And all was good.
But I just did my first dnf update and was surprised to find these lines in the log of the dnf update:
---> Package moin.noarch 1.9.10-3.fc31 will be erased ---> Package python2-mod_wsgi.x86_64 4.6.6-2.fc32 will be erased
What is forcing the erase? I need to workaround this.
fedora-obsolete-packages I guess.
Just build the packages you need with newer version/release. Then python3 subpackage or fedora-obsolete-packages won't remove them.
Thanks for the explanation.
I'll package as barry-XXX to avoid the problem.
Barry
Barry _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Igor Raits ignatenkobrain@fedoraproject.org -----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl64L48ACgkQEV1auJxc Hh678xAAo/orxcpLxsOaAAmusa/THRWnHbt8/DTcjZXOB04WzL7gd/jb6HqO/bgg bihxGGyzDiFSGi/cIiZ7X9Tweiq2IynjSep2fhVlNUBKcIKKmPaJkDWIlqTaPt+n hRpDzKaowwFLHs2N9N9rsQQPm5NLbIIhEH00aWg5KqZ1OErMT2cqM9MS7nLLOakP nRqkC+9dbUx8kFdVMDedWQlH1tW2SDi+9mpX6TXqizJuOGHBAIGqhILcrUB8suJl vM5XElvHEObmtRksglCjJ+Ogou57SDN0jOik7nwhCvxDgxbC+/DIMPWNXyykWCON mkasRJMmhpbSx8JJ5aNnbeCnn9d6NrQv4T9TxriQjzZTs+NUvbYGHmJxQHExEUmP A0Ix7V5t8SgKuZ6P9cwlQqEagwntjIr8vyxs6YZscT0L5CGXL1LEKETQRI61JhdG /dMIB47qU78HJn/MQmYjyBic5wp7+PrGqPaTtdxxX0Jr/U0HgqLL4JVuN9EVKypb rY4ucKqVW4MCHGY2IxLXIbdcoeFtypqwoJagXbf1kBV9fMpVUcPcJqhfNAC29yt1 I0a2qGlBC9PatWQ6TKPhobVfWFJA//RAvFiRVKnupe6+0aynaT+j377tJoGu9Cdj rkatM+zxroo2WjcDkgBvbcjuD1t42y3J46rfn78l1+aHrMPwXgY= =Rukt -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org