What is force erasing python 2 packages like moin?

[Barry Scott]

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

[Scott Talbert]

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/fe...

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

[Miro Hrončok]

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/fe...
>
>  
>  
>  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

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Kevin Fenzi]

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/fe...
>  > 
>  > 
>  > 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

[Fabio Valentini]

On Sun, May 10, 2020 at 8:49 PM Kevin Fenzi <kevin(a)scrye.com&gt; 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/fe...
>  > >
>  > >
>  > > 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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Zbigniew Jędrzejewski-Szmek]

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(a)scrye.com&gt;
> 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/fe...
>  > > >
>  > > >
>  > > > 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

[Miro Hrončok]

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.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Zbigniew Jędrzejewski-Szmek]

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

[Miro Hrončok]

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.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miroslav Suchý]

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.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

[Kevin Fenzi]

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

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Miro Hrončok]

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



-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Neal Gompa]

On Mon, May 11, 2020 at 7:23 PM Miro Hrončok <mhroncok(a)redhat.com&gt; 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Igor Raits]

-----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(a)redhat.com&gt;
>  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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl66Ky8ACgkQEV1auJxc
> Hh5nxQ/9H1T7TETYhJR39LvtSjxFYKwiFZRhbV06+aV7K8e99tAUZ0JCOpc7cmIq
> mTIs/cQ4QvoiwgYfaGSmMFOV13CK8Lfq+LhqPAvtru+b7HFgmWdb09kO/UcTjXjm
> TEwSd7fuhXXTGhDcstt5p9qfXbvgua3j9/N3N8N8srTsCXm9sD/JjGN5lj5rqZSO
> 0IQZAwJfIc42v+CT//f8RFv+/tHybx9gKysfnjzs55ZdRQQWF6sLljcsZff6Q58t
> oMB/p19EBObN3y9DXU7YxlHOz0kWij5+2ZRX7kxhM1zhpe/t3/N1GSIsMeIbOOEe
> YWqUGybVorlSiaFQ6IAgeDJsqr4hCUvtM0WNbHI+Qu+T63F5RY22AS+9QlANkv2b
> 8gwucFq/f9bb4qFBsAFH0hAOMqf6GBeuu0NpflKVzZYTynxfXi8lLBZo0TPTktCn
> IuHxKNH2uos77d0+Py1I/dhmkkoRwk59pTK4jcGTNC1R46m7UgNi2D4albXJu6lb
> ki4oGhYO5HzUKoELRZ8PuLa5207sWdJs6W3Rqz2HSfDhKdhUfa2J6Y7umA+PjnOj
> ocaX3tyug/JfZ0sWelWecPWF7Nifc4U4qGxb2Q7rlGFeapUHwYc4L0Q+NmuebpDw
> kMKOINOmvWErTaiIMGEaLIV+cekfblhEAUTvesRGXJcrW8jHfAM=
> =c9YB
> -----END PGP SIGNATURE-----

[Neal Gompa]

On Sun, May 10, 2020 at 12:32 PM Barry Scott <barry(a)barrys-emacs.org&gt; 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



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Igor Raits]

-----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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail] 
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----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-----

[Barry Scott]

>  On 10 May 2020, at 17:45, Igor Raits
> <ignatenkobrain(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  - -- 
>  Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> >  -----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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]