remove-retired-packages

[Miroslav Suchý]

Hi.

I created small script `remove-retired-packages`. You can try it using:

$ sudo dnf copr enable msuchy/remove-retired-packages

$ remove-retired-packages

This script removes packages retired between Fedora N and Fedora N-1. You can run it with
parameter:

$ remove-retired-packages  30

And it will remove all packages retired between Fedora N and Fedora 30.

It removes packages one-by-one. And you have the option to skip specific package.

The source is here:

https://github.com/xsuchy/fedora-upgrade/blob/main/remove-retired-packages

I will welcome PR. Especially for the wording of the printed text.

If I get positive feedback I turn this into F36 Change proposal.

Miroslav

[Miro Hrončok]

On 24. 09. 21 6:44, Miroslav Suchý wrote:
>  Hi.
>  
>  I created small script `remove-retired-packages`. You can try it using:
>  
>  $ sudo dnf copr enable msuchy/remove-retired-packages
>  
>  $ remove-retired-packages
>  
>  This script removes packages retired between Fedora N and Fedora N-1. You can 
>  run it with parameter:
>  
>  $ remove-retired-packages  30
>  
>  And it will remove all packages retired between Fedora N and Fedora 30.
>  
>  It removes packages one-by-one. And you have the option to skip specific package.
>  
>  The source is here:
>  
>  https://github.com/xsuchy/fedora-upgrade/blob/main/remove-retired-packages 
Should it query for removed packages instead of components?

It seem that when python-foo is retired, the script will attempt to remove 
python-foo instead of python3-foo (and python3-foo-docs etc.).

PS That's why I mentioned both options when answering your "how to find out 
what has been retired" question. The solution is to stop using the source repos 
(and src arch).

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

[Miro Hrončok]

On 24. 09. 21 10:50, Miro Hrončok wrote:
>  On 24. 09. 21 6:44, Miroslav Suchý wrote:
> > Hi.
> >
> > I created small script `remove-retired-packages`. You can try it using:
> >
> > $ sudo dnf copr enable msuchy/remove-retired-packages
> >
> > $ remove-retired-packages
> >
> > This script removes packages retired between Fedora N and Fedora N-1. You can 
> > run it with parameter:
> >
> > $ remove-retired-packages  30
> >
> > And it will remove all packages retired between Fedora N and Fedora 30.
> >
> > It removes packages one-by-one. And you have the option to skip specific 
> > package.
> >
> > The source is here:
> >
> > https://github.com/xsuchy/fedora-upgrade/blob/main/remove-retired-packages
>  
>  Should it query for removed packages instead of components?
>  
>  It seem that when python-foo is retired, the script will attempt to remove 
>  python-foo instead of python3-foo (and python3-foo-docs etc.).
>  
>  PS That's why I mentioned both options when answering your "how to find out 
>  what has been retired" question. The solution is to stop using the source repos 
>  (and src arch). 
Another idea: The script currently needs fedora-packager (for the pkgname 
command). If you use --qf=%{NAME} in the repoquery, it won't.

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

[Marek Blaha]

On Fri, Sep 24, 2021 at 10:58 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  > Should it query for removed packages instead of components?
>  >
>  > It seem that when python-foo is retired, the script will attempt to remove
>  > python-foo instead of python3-foo (and python3-foo-docs etc.).
>  >
>  > PS That's why I mentioned both options when answering your "how to find
> out
>  > what has been retired" question. The solution is to stop using the source
> repos
>  > (and src arch).
>
>  Another idea: The script currently needs fedora-packager (for the pkgname
>  command). If you use --qf=%{NAME} in the repoquery, it won't. 
Yes, I've already created a small PR on those dependencies (another is
using `dnf repoquery` instead of `repoquery` that drops depencendy on
dnf-utils package).
And I agree that the script should use packages instead of source
packages - currently the results are really wild - a lot of packages
is suggested for removal without being actually retired.

But still I'd rather have this as part of distribution - a package
similar to fedora-obsolete-packages which would allow me to remove all
retired packages simply by installing it.
Oh there is already this proposal -
https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages

Marek Blaha

[Miroslav Suchý]

Dne 24. 09. 21 v 11:27 Marek Blaha napsal(a):
> >> It seem that when python-foo is retired, the script will
> attempt to remove
> >> python-foo instead of python3-foo (and python3-foo-docs etc.). 
Oh. Silly me. I will fix this.

> > Another idea: The script currently needs fedora-packager (for the
> pkgname
> > command). If you use --qf=%{NAME} in the repoquery, it won't.
>  Yes, I've already created a small PR on those dependencies (another is
>  using `dnf repoquery` instead of `repoquery` that drops depencendy on
>  dnf-utils package). 
Thank you.
>  But still I'd rather have this as part of distribution - a
> package
>  similar to fedora-obsolete-packages which would allow me to remove all
>  retired packages simply by installing it.
>  Oh there is already this proposal -
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages 
And in the followup discussion this was rejected as a bad idea.

Example: one of the retired packages is "nspr" but if you try to remove it, then
half of your system is gone. :)

Therefore it is a good idea to allow user to "cherry-pick" packages which should
be kept on machine despite being retired.

Miroslav

[Miro Hrončok]

On 24. 09. 21 12:31, Miroslav Suchý wrote:
> > But still I'd rather have this as part of distribution - a
> package
> > similar to fedora-obsolete-packages which would allow me to remove all
> > retired packages simply by installing it.
> > Oh there is already this proposal -
> > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>  
>  And in the followup discussion this was rejected as a bad idea.
>  
>  Example: one of the retired packages is "nspr" but if you try to remove it, 
>  then half of your system is gone. :)
>  
>  Therefore it is a good idea to allow user to "cherry-pick" packages which 
>  should be kept on machine despite being retired. 
I think w are over-engineering a workaround for something that could be part of 
system-upgrade. See my proposal in 
https://lists.fedoraproject.org/archives/list/[e-mail].o...

that got 0 replies:

>  Generally, I think we should instead strive to have configurable
> bahavior of dnf 
>  system-upgrade:
>  
>    option 1) broken deps block upgrades, user go figure (status quo)
>    option 2) broken deps of packages not part of distupgrade repository behave 
>  like --allowerasing
>    option 3) all packages not part of distupgrade repository are removed on 
>  distro boundary upgrade
>    option 4) --allowerasing (already possible)
>  
>  With alterations for 2/3:
>  
>    suboption a) this affects all packages
>    suboption b) this affects only packages installed from "system repos"
>  
>  (Suboption b) can be achieved trough a .repo file configuration option.)
>  
>  Then we can have a discussion about the best default for Fedora.
>  
>  Such solution obviously requires somebody to design it, code it, test it, 
>  support it and maintain it. I cannot speak for the software management team, but 
>  I guess they would have reasons not to do that (such as capacity reasons). 


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

[Miroslav Suchý]

Dne 24. 09. 21 v 13:55 Miro Hrončok napsal(a):
>  I think w are over-engineering a workaround for something that could
> be part of system-upgrade. See my proposal in 
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>
>  that got 0 replies:
>
> > Generally, I think we should instead strive to have configurable bahavior of dnf
> system-upgrade:
> > ....SNIP
> > Such solution obviously requires somebody to design it, code it, test it, support it
> and maintain it. I cannot speak 
> > for the software management team, but I guess they would have reasons not to do that
> (such as capacity reasons).  
DNF team has its priority list already packed. I think it make sanse to do this designing
phase in separate tool. And 
only when it becomes obvious what we want and how to do it, only then merge it to core DNF
code.

Miroslav

[Miroslav Suchý]

Dne 24. 09. 21 v 10:50 Miro Hrončok napsal(a):
>  Should it query for removed packages instead of components?
>
>  It seem that when python-foo is retired, the script will attempt to remove python-foo
> instead of python3-foo (and 
>  python3-foo-docs etc.).  
This is fixed now. And build with the fix is in the Copr repository (link is in first mail
in this thread).

Miroslav

[Vitaly Zaitsev]

On 24/09/2021 06:44, Miroslav Suchý wrote:
>  I created small script `remove-retired-packages`. You can try it
> using: 
Much more simple script:

sudo dnf remove $(dnf -C list extras | cut -d ' ' -f -1 | tail -n +3)

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Miroslav Suchý]

Dne 24. 09. 21 v 11:59 Vitaly Zaitsev via devel napsal(a):
>  sudo dnf remove $(dnf -C list extras | cut -d ' ' -f -1 |
> tail -n +3)  
This will remove packages which are not in current repositories.

On my workstation, this will suggests to remove webex, which I installed manually as an
rpm. And I definitelly want to 
keep it.

My current implementation is more conversative and remove only packages which were
presented at some point in Fedora and 
now are retired.

It is so conservative, that it even leave behind the packages from N-2 version.

Miroslav