Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages

== Summary ==
All retired packages are obsoleted by `fedora-retired-packages`.

== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Email: msuchy(a)redhat.com

== Detailed Description ==
Right now `fedora-obsoletes-package` retires packages which cause an
issue during an upgrade. We do nothing about all other retired
packages. Now imagine the following story (it already happened many
times):

We have package "foo". It is a leaf package. No one requires it. It
uses just basic libraries.
A user installs it during F32 lifetime.

Around F35 the upstream dies. Around F37 Fedora maintainer retires the
package (or orphan and it later become retired).

Because the package is a leaf package, it causes no pain during
upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
then during upgrade to F43 it suddenly causes a problem. But because
it is .fc37 everyone will hesitate to add it
fedora-obsolete-packages.fc43.

Additionally, during F38-F43, users may expect that their system is
fully updated and they have no security issues. But it is not true
about package "foo", which no one maintains. And users are not aware
of that because he does not follow fedora-devel mailing list.
Obviously.

What I propose is: As part of the retirement process we add the to
fedora-retired-packages:
  Obsoletes: foo < %{latestversion+1}
And during upgrade from F37->F38 the package will be removed.

If the user wants to preserve the package (e.g., because it moved to
Copr), he simply uninstalls and protects the installation of
fedora-retired-packages. But that will be an informed decision.

The benefits are:
 * we do not leave unmaintained packages on a user's machine.
 * We make sure that archaic packages do not break upgrade between two
versions of Fedora.

== Feedback ==

After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
discussion with fedora-obsolete-package maintainer] I filed this
Change proposal to include a wider audience.

See relevant
[https://lists.fedoraproject.org/archives/list/[e-mail].o...
thread on devel mailing list].

== Benefit to Fedora ==
 * We do not leave unmaintained packages on a user's machine.
 * We make sure that archaic packages do not break upgrade between two
versions of Fedora.

== Scope ==
* Proposal owners:

Create package `fedora-retired-packages` as sub-package of
`fedora-obsolete-packages`
[https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
Edit
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
guidelines with:

The retired package should be obsoleted by one of:

 * fedora-obsoleted-packages - if the package can cause problem during
upgrade to next version of Fedora
 * fedora-retired-packages - in all other cases

It is enough to open an issue on
https://src.fedoraproject.org/rpms/fedora-obsolete-packages

* Other developers:
No other work should be necessary.

* Release engineering:
This is optional. I may work with rel-eng to change
https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pa...
to automatically create PR for `fedora-obsolete-packages`

* Policies and guidelines: As stated above
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
will need an update.

* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
During an upgrade, all retired packages will be automatically removed.

User may opt-out by:
<pre>
$ cat /etc/dnf/dnf.conf
[main]
...
exclude=fedora-retired-packages
</pre>


== How To Test ==
1. Upgrade to next version of Fedora.
2. Check all retired packages are removed.

== User Experience ==
 - Packages that are no longer maintained are removed during a
distribution upgrade.

== Dependencies ==
This update has no dependencies on any other package.

== Contingency Plan ==
* Contingency mechanism: Drop `fedora-retired-package`. Or remove
`Obsoletes` from this sub-package.
* Contingency deadline: Beta freeze
* Blocks release? No

== Documentation ==
TBD

== Release Notes ==
TBD


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Igor Raits]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2020-06-15 at 15:47 -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>  
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`.
>  
>  == Owner ==
>  * Name: [[User:msuchy| Miroslav Suchý]]
>  * Email: msuchy(a)redhat.com
>  
>  == Detailed Description ==
>  Right now `fedora-obsoletes-package` retires packages which cause an
>  issue during an upgrade. We do nothing about all other retired
>  packages. Now imagine the following story (it already happened many
>  times):
>  
>  We have package "foo". It is a leaf package. No one requires it. It
>  uses just basic libraries.
>  A user installs it during F32 lifetime.
>  
>  Around F35 the upstream dies. Around F37 Fedora maintainer retires
>  the
>  package (or orphan and it later become retired).
>  
>  Because the package is a leaf package, it causes no pain during
>  upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
>  then during upgrade to F43 it suddenly causes a problem. But because
>  it is .fc37 everyone will hesitate to add it
>  fedora-obsolete-packages.fc43.
>  
>  Additionally, during F38-F43, users may expect that their system is
>  fully updated and they have no security issues. But it is not true
>  about package "foo", which no one maintains. And users are not aware
>  of that because he does not follow fedora-devel mailing list.
>  Obviously.
>  
>  What I propose is: As part of the retirement process we add the to
>  fedora-retired-packages:
>    Obsoletes: foo < %{latestversion+1}
>  And during upgrade from F37->F38 the package will be removed.
>  
>  If the user wants to preserve the package (e.g., because it moved to
>  Copr), he simply uninstalls and protects the installation of
>  fedora-retired-packages. But that will be an informed decision.
>  
>  The benefits are:
>   * we do not leave unmaintained packages on a user's machine.
>   * We make sure that archaic packages do not break upgrade between
>  two
>  versions of Fedora. 
I fully agree with the benefits, however I do not like the approach.
Why not to teach DNF system-upgrade about special flag (like --remove-
unmaintained-packages) that will take installed packages, available
packages and remove those that do not exist in the target repo?

>  == Feedback ==
>  
>  After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
>  discussion with fedora-obsolete-package maintainer] I filed this
>  Change proposal to include a wider audience.
>  
>  See relevant [
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  thread on devel mailing list].
>  
>  == Benefit to Fedora ==
>   * We do not leave unmaintained packages on a user's machine.
>   * We make sure that archaic packages do not break upgrade between
>  two
>  versions of Fedora.
>  
>  == Scope ==
>  * Proposal owners:
>  
>  Create package `fedora-retired-packages` as sub-package of
>  `fedora-obsolete-packages`
>  [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
>  Edit 
>
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
>  guidelines with:
>  
>  The retired package should be obsoleted by one of:
>  
>   * fedora-obsoleted-packages - if the package can cause problem
>  during
>  upgrade to next version of Fedora
>   * fedora-retired-packages - in all other cases
>  
>  It is enough to open an issue on
>  https://src.fedoraproject.org/rpms/fedora-obsolete-packages
>  
>  * Other developers:
>  No other work should be necessary.
>  
>  * Release engineering:
>  This is optional. I may work with rel-eng to change
>  https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pa...
>  to automatically create PR for `fedora-obsolete-packages`
>  
>  * Policies and guidelines: As stated above
>
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
>  will need an update.
>  
>  * Trademark approval: N/A (not needed for this Change)
>  
>  
>  == Upgrade/compatibility impact ==
>  During an upgrade, all retired packages will be automatically
>  removed.
>  
>  User may opt-out by:
>  <pre>
>  $ cat /etc/dnf/dnf.conf
>  [main]
>  ...
>  exclude=fedora-retired-packages
>  </pre>
>  
>  
>  == How To Test ==
>  1. Upgrade to next version of Fedora.
>  2. Check all retired packages are removed.
>  
>  == User Experience ==
>   - Packages that are no longer maintained are removed during a
>  distribution upgrade.
>  
>  == Dependencies ==
>  This update has no dependencies on any other package.
>  
>  == Contingency Plan ==
>  * Contingency mechanism: Drop `fedora-retired-package`. Or remove
>  `Obsoletes` from this sub-package.
>  * Contingency deadline: Beta freeze
>  * Blocks release? No
>  
>  == Documentation ==
>  TBD
>  
>  == Release Notes ==
>  TBD
>  
>  
>  -- 
>  Ben Cotton
>  He / Him / His
>  Senior Program Manager, Fedora & CentOS Stream
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to 
>  devel-announce-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-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n0oQACgkQEV1auJxc
> Hh5v4BAAmjdMeYnF5GMjdH30EweQAz1Wsjex/QN/yUP3GOt50EPfy4jbU2RIwije
> RvwKkJF6JAgEY+Q+mKvRWRlTIu3cBA/Kh4qQS/LDzRSuRba6ZUBeZ3aG4Pe1fn4L
> XubI8pBHWPfO7W4w3nsF8ivSQoLighQm3/Ee/FqdAUmeD+ZyCqWZLV+hWMX45fMY
> LSlBLp+Lx7m0INWNBB5lxiXtvx66pBicyAp3YbWmfWGls8TdSMqpIEhSAizPM+Mn
> Kg09SkQqNtEydSAOS+TZi1fe5mQJKWGdaxTXEfUUO5pRSmIt/JR6uDltgru4ltWe
> 1eeN3Agp8xltChY8oadlK1SdPL5msjxguKVe1vMjoSXsQKzT53gzVAmeN2lCCnyT
> 122O2qklsG0RV4lx19aIAKpvq43gUnUAKXT6dZVbLIzh5UBfK2qGRuT6KNNVrRb8
> N+fnkYqJ4XDPLdvoaAWdAAFn/WohV3/IXdX5jbN1XahJo5kxO7ePc1TVh0u2A4UW
> 9qdpAU8P0M5zKoreRWwvTkLKSWdz9wRnPJA0iZgxIWFbOBytmYxlKJzNGlGPKt1N
> r1dYid3q2QGX5OXNJvwnARQThRTtC+Q295/AF4EPKb4LsV0w7qUYKSe8kjYBRHxv
> yezHkTo2EUt4JKB6R64m7e05tDRP7wLMTdzLaxxPem+32Ap3cFM=
> =fm7+
> -----END PGP SIGNATURE-----

[Solomon Peachy]

On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
>  What I propose is: As part of the retirement process we add the to
>  fedora-retired-packages:
>    Obsoletes: foo < %{latestversion+1}
>  And during upgrade from F37->F38 the package will be removed. 
Gah, no.  Just.. no.

This will silently break otherwise-working software on production 
systems, and provide no straightforward way to get back to a working 
state.

>  If the user wants to preserve the package (e.g., because it moved to
>  Copr), he simply uninstalls and protects the installation of
>  fedora-retired-packages. But that will be an informed decision. 
So.. the package is dropped because it's not being maintained, yet.. 
it's being maintained in copr?  How often does this really happen?

>  The benefits are:
>   * we do not leave unmaintained packages on a user's machine. 
What about software installed from 3rd-party repositories?  What about 
packages that were downloaded and installed directly from ISVs?

>   * We make sure that archaic packages do not break upgrade between
> two
>  versions of Fedora. 
This is a laudable goal, but... surely a better approach is to improve 
the diagnostics when faced with upgrade failures?  That way the user 
will be able to make an informed choice at the time the problem would 
have occurred, rather than having the software (which they might be 
reliant upon) silently disappearing.

I say this as someone who has run into this problem quite often over the 
years, including on the machine I'm using to write this email.  
Sometimes the correct solution is to remove the old package, but other 
times that package is in active use.


 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[Miro Hrončok]

On 15. 06. 20 21:56, Igor Raits wrote:
>  I fully agree with the benefits, however I do not like the approach.
>  Why not to teach DNF system-upgrade about special flag (like --remove-
>  unmaintained-packages) that will take installed packages, available
>  packages and remove those that do not exist in the target repo? 
I also think this is better than the proposed change.

However, if we cannot have this yet, maybe the change is the best we could get now?

That said, without 100 % automation, the proposed system is not manageable either.

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

[Kevin Fenzi]

On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
...snip...

>  If the user wants to preserve the package (e.g., because it moved to
>  Copr), he simply uninstalls and protects the installation of
>  fedora-retired-packages. But that will be an informed decision. 
How is this discoverable? It's already really unclear that
fedora-obsolete-packages should be excluded if you want to keep obsolete
packages. :( 

kevin

[James Cassell]

On Mon, Jun 15, 2020, at 6:07 PM, Kevin Fenzi wrote:
>  On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>  
>  ...snip... 
Please not using mechanism. Make it easy to opt out, or better yet opt-in. Probably better
to just advertise `yum list extras` which has existed since at least Fedora 12.

>  
>  > If the user wants to preserve the package (e.g., because it moved to
>  > Copr), he simply uninstalls and protects the installation of
>  > fedora-retired-packages. But that will be an informed decision.
>  
>  How is this discoverable? It's already really unclear that
>  fedora-obsolete-packages should be excluded if you want to keep obsolete
>  packages. :( 
>   
Agreed. We should kill the auto destruct on this package. It makes it very confusing why
something it's being removed. Or at least make it obvious in the output why things are
being removed.


V/r,
James Cassell

[Ian McInerney]

>  ...snip...
>
>  What I propose is: As part of the retirement process we add the to
>  fedora-retired-packages:
>    Obsoletes: foo < %{latestversion+1}
>  And during upgrade from F37->F38 the package will be removed.
>
>  
I am not a fan of this part. One release cycle seems awfully tight for
this, and it also doesn't give the user an obvious override. I have had
packages in the past hang around (I recently cleaned off some f27-era
packages from my laptop when I upgraded it to f31) and then cleaned them
off manually (listing them through `rpm -qa | grep fcXX` and then manually
removing them), but I think it would be better to warn on upgrade when
those packages don't exist in the newer release to tell the user they
aren't around. Then they can make the decision on what to do with them.
(how this is exposed in UIs, I am not sure).


>  If the user wants to preserve the package (e.g., because it moved to
>  Copr), he simply uninstalls and protects the installation of
>  fedora-retired-packages. But that will be an informed decision.
>
>  The benefits are:
>   * we do not leave unmaintained packages on a user's machine.
>   * We make sure that archaic packages do not break upgrade between two
>  versions of Fedora.
>  
How large a problem is this? I have had several f27-f30 packages installed
on a machine that was successfully upgraded to f31 (and several others in
between) with no issues. I am fine with saying if a package could cause
upgrade issues then we explicitly remove it (like what was done for the
python2 packages on the f31->f32 upgrade by marking them in
fedora-obsolete-packages). I would imagine that this isn't a large problem
for leaf packages at first, but could be a larger issue if a library they
required was removed.


>  == Feedback ==
>
>  After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
>  discussion with fedora-obsolete-package maintainer] I filed this
>  Change proposal to include a wider audience.
>
>  See relevant [
>
> https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  thread on devel mailing list].
>
>  == Benefit to Fedora ==
>   * We do not leave unmaintained packages on a user's machine.
>   * We make sure that archaic packages do not break upgrade between two
>  versions of Fedora.
>
>  == Scope ==
>  * Proposal owners:
>
>  Create package `fedora-retired-packages` as sub-package of
>  `fedora-obsolete-packages`
>  [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
>  Edit
>
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
>  guidelines with:
>
>  The retired package should be obsoleted by one of:
>
>   * fedora-obsoleted-packages - if the package can cause problem during
>  upgrade to next version of Fedora
>   * fedora-retired-packages - in all other cases
>  
Isn't this split between the two packages basically saying this change
doesn't have the second benefit that is claimed above? If packages that
would break an upgrade are added to fedora-obsolete-packages, then the only
benefit left would appear to be that no unmaintained packages are left on a
user's machine - the archaic packages that could break an upgrade can
already be fixed by adding them to fedora-obsolete-packages without this
change.


>  It is enough to open an issue on
>  https://src.fedoraproject.org/rpms/fedora-obsolete-packages
>
>  * Other developers:
>  No other work should be necessary.
>
>  * Release engineering:
>  This is optional. I may work with rel-eng to change
>
>  https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pa...
>  to automatically create PR for `fedora-obsolete-packages`
>
>  
How would unretirement of a package marked in fedora-retired-packages work?
Would there be a similar automatic method to unretire the package and push
an update to the fedora-retired-packages package so that it can be
installed again? Would this list of retired packages be checked on every
transaction, or just on system upgrades?


>  * Policies and guidelines: As stated above
>
>
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
>  will need an update.
>
>  * Trademark approval: N/A (not needed for this Change)
>
>
>  == Upgrade/compatibility impact ==
>  During an upgrade, all retired packages will be automatically removed.
>
>  User may opt-out by:
>  <pre>
>  $ cat /etc/dnf/dnf.conf
>  [main]
>  ...
>  exclude=fedora-retired-packages
>  </pre>
>  
This seems very drastic if the user just wanted one package to stay. This
would basically revert to the old behavior in that case.


>  ...snip...
>  
-Ian

[Miroslav Suchý]

Dne 15. 06. 20 v 22:43 Solomon Peachy napsal(a):
>  This will silently break otherwise-working software on production 
>  systems, and provide no straightforward way to get back to a working 
>  state. 
Can you give example?

>  What about software installed from 3rd-party repositories?  What
> about 
>  packages that were downloaded and installed directly from ISVs? 
Should not be affected.


>  This is a laudable goal, but... surely a better approach is to
> improve 
>  the diagnostics when faced with upgrade failures?  That way the user 
>  will be able to make an informed choice at the time the problem would 
>  have occurred, rather than having the software (which they might be 
>  reliant upon) silently disappearing. 
Informed choice...?

I'll give two use-cases.

PlayOnLinux - this is a piece of SW I used to use. It caused an issue during upgrade to
F32 and it has been added to
fedora-obsolete-packages. Yet, when DNF told me it has to be removed, I reacted "WTF,
I am using it". I looked up the
information and then I made an informed decision.

libgltf - This is actually a random package with *fc29* on my workstation. Hmm, one moment
- yeah, dead package. I do
not even know what it does, why it happened to be on my computer. Hmmm, yes - nothing
requires it. It can be safely
removed. And it is gone. Is it something silently using this, when it is present? Does it
have some security issues? I
thought that when I was doing "dnf upgrade" every week, that I have secure
system. Do I want to spend some time on this
to make informed decision? No. Too many question, I have other things to do.


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

[Miroslav Suchý]

Dne 16. 06. 20 v 0:40 Ian McInerney napsal(a):
>  and then cleaned them off manually (listing them through `rpm -qa |
> grep fcXX` and then manually removing them), but I
>  think it would be better to warn on upgrade when those packages don't exist in the
> newer release to tell the user they
>  aren't around. Then they can make the decision on what to do with them. 
This is what actually `fedora-upgrade(8)` does at the end of upgrade. The problem is that
every release, we have some
fail-to-build package in the compose and the new release contains the package from the
previous release. But they should
not be removed. E.g., In Fedora 32 is js-html5shiv.fc31

https://src.fedoraproject.org/rpms/js-html5shiv/tree/master
https://koji.fedoraproject.org/koji/packageinfo?packageID=26061

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

[Miroslav Suchý]

Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
>  Please not using mechanism. Make it easy to opt out, or better yet
> opt-in. 
On package level, there is likely no other way. DNF team will have no time/resources to
implement this on DNF level.
I can only thing of /usr/sbin/remove-retired-package which would be a wrapper for
  dnf remove $list $of $retired $package
Does that sounds better?

Is there some way how to get this information from PDC?

>  Probably better to just advertise `yum list extras` which has existed
> since at least Fedora 12. 
Will be my mom able to write something like:
 dnf remove $(dnf list extras | awk '{print $1} | grep -v
"package-I-still-want")
?
On my system this prints 124 package. Half of them are from 3rd party repositories or from
command line and I want to
preserver them. So I even cannot use the command above. And it is easier to remove them
one by one. This is painful.

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

[Solomon Peachy]

On Tue, Jun 16, 2020 at 12:46:30AM +0200, Miroslav Suchý wrote:
>  Can you give example? 
I have a F30 system running the F29 mailgraph package, which was 
retired.  It was the last remaining blocker preventing that system from 
being upgraded to F31.  (The others were due to non-fedora-packaged 
deprecated perl stuff..)

(I have since rebuilt the package for F31, and I will be using that 
self-maintained package instead of having to come up with something to 
replace mailgraph's functionality.  Not to mention historical data..)

>  > What about software installed from 3rd-party repositories?  What
> about 
>  > packages that were downloaded and installed directly from ISVs?
>  
>  Should not be affected. 
So why would software supplied by fedora be treated differently than 
third-party software?  

>  PlayOnLinux - this is a piece of SW I used to use. It caused an issue
>
>  during upgrade to F32 and it has been added to 
>  fedora-obsolete-packages. Yet, when DNF told me it has to be removed, 
>  I reacted "WTF, I am using it". I looked up the information and then I 
>  made an informed decision. 
So did you make the informed decision to not upgrade, or to remove it 
anyway?

(playonlinux was one of the many casualties of the python2 retirement
 debacle.  Not Fedora's fault..)

>  libgltf - This is actually a random package with *fc29* on my 
>  workstation. Hmm, one moment - yeah, dead package. I do not even know 
>  what it does, why it happened to be on my computer. Hmmm, yes - 
>  nothing requires it. It can be safely removed. And it is gone. Is it  
Yup; you made that decision -- because DNF couldn't have known if you 
needed it or not -- this is especially true for a leaf library.  What if 
you had some software you'd compiled from source that relied on that 
library?

By all means, let's obsolete stuff that has proper replacements (eg 
library or package renames) but auto-removing software simply because 
fedora no longer packages it is not user-friendly and leads to 
unpleaseant surprises.

And yes, I know the 'dnf system-upgrade download' output will list stuff 
it's removing, but it's all too easy to miss something in that 3000-odd 
line dump.  I consider an explicit error to be far more informative, 
although I suppose splitting apart those "retired packages causing 
conflicts" packages into a separate list on the system-upgrade output 
would IMO be a much better approach.

(Did I miss when Fedora changed their policies to auto-remove 
 applications or libraries simply because they're no longer packaged?  
 The python2->3 debacle notwithstanding...)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[Kevin Kofler]

Ben Cotton wrote:
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`.
>  
>  == Owner ==
>  * Name: [[User:msuchy| Miroslav Suchý]]
>  * Email: msuchy(a)redhat.com 
Absolute -1!

IMHO, removing working packages from users' systems just because the new 
release no longer ships them is entirely unnecessary and a total disservice 
to users.

>  == Upgrade/compatibility impact ==
>  During an upgrade, all retired packages will be automatically removed.
>  
>  User may opt-out by:
>  <pre>
>  $ cat /etc/dnf/dnf.conf
>  [main]
>  ...
>  exclude=fedora-retired-packages
>  </pre> 
Is this actually honored by all tools, including PackageKit? (Last I 
checked, PackageKit ignored dnf.conf entirely.) The opt-out needs to work 
with PackageKit to be of any use.

        Kevin Kofler

[Miro Hrončok]

On 15. 06. 20 21:47, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>  
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`. 
My general feedback:

+ I agree that removing retired and otherwise removed packages on release 
boundary upgrade is a reasonable default (with possible opt out).

- I do not think that doing this via obsoletes is the best way to achieve that 
goal. Already now, the situation is confusing to users wrt 
fedora-obsolete-packages. (However I realize that this is something that can be 
driven by a proposal like this easier than driving dnf system upgrade behavior 
changes.)

- I do not want to maintain the information in the package metadata and keep it 
up to date. Who does this? Note that releng does not follow the linked 
sop_retire_orphaned_packages.rst at all. And even if we manage to get "fedpkg 
retire" do the thing 100 % automatically, note that if a package gets removed 
from Fedora N, and is obsoleted via fedora-obsolete-packages (or 
fedora-retired-packages in case of this proposal), every time it is updated in 
Fedora N-1 and/or Fedora N-2, the obsoleted version must be updated. There is no 
automation for this and I have been doing it manually when people file bugzillas 
or complain on the mailing lists. It is an ungrateful, tedious and never ending job.

- There are retired packages ("components", "source packages") and
removed 
packages ("built packages", "binary", "subpackages"). The
problem is that when 
we retire a component, we need to obsolete all packages it (used to) create. 
Naturally, this is not always easy to grasp for packagers: Even the change does 
not consider the difference at all. Retirement also isn't the only way to remove 
a package (subpackages get removed as well).



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).


The solution proposed in the change OTOH requires somebody to create the 
package, create the automation, keep it up to date, explain to users how to opt 
out, explain to packagers what to do, fight broken data, keep it up to date 
after the data has been changed by a provenpackager who doesn't understand this 
(happens every once in a while with fedora-obsolete-packages), test it 
continuously, support different datasets for up to 4 different releases.

As one of the fedora-obsoelte-packages maintainers, I have capacity reasons not 
to do this.

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

[Kamil Paral]

On Mon, Jun 15, 2020 at 9:50 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`.
>  
I'll not talk about implementation, there are more suitable people for that
here. But I'll voice my opinion that automatically retiring software from
Fedora users' computers is a sane and proper thing to do. If a package is
removed from Fedora, it should also be removed from users computers (during
FN+1 upgrade). Of course, we should allow users to keep it, if they want
it. But the default process should happen automatically, and users should
opt-out of automatic retiring, instead of opt-in. Only this way we can
build a secure and reliable operating system.

If only power users can opt-out from retiring a package (e.g. by editing
dnf.conf), I don't think that's a problem. Because even though general
users will of course be unhappy when an application they use get
permanently removed during system upgrade, they will be even more unhappy
when their system suddenly breaks in the future, either by unresolved
dependencies, or when the retired app/library causes the system to not boot
or breaks the desktop, because nobody at that points expects and tests
those software interactions. A general user can resolve a missing app, but
they can't resolve a broken OS. If they want to deviate from the system we
provide, it's reasonable to ask them to have certain technical knowledge,
instead of allowing them to shoot themselves in the foot (even unknowingly,
by not doing automatic retirement).

So on this level (and ignoring implementation), I'm in favor of this
proposal - make it automatic and allow opt-out (targeting just power users
for opt-out is fine).

[Vít Ondruch]

I have sympathy for such proposal, but the implementation does not
respect all the possible corner cases.

1) It does not reflect, that this is not just about retired packages,
but also (or mainly?) about subpackages, which we don't retire.

2) The point (1) is closely related to -debuginfo packages topic [1]
which I re-raised recently with not as much attention as I would like.

Also, I wonder what is wrong with "dnf autoremove", which is supposed to
remove unused leaf packages, which were not explicitly installed?


Vít



[1]
https://lists.fedoraproject.org/archives/list/[e-mail].o...


Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`.
>
>  == Owner ==
>  * Name: [[User:msuchy| Miroslav Suchý]]
>  * Email: msuchy(a)redhat.com
>
>  == Detailed Description ==
>  Right now `fedora-obsoletes-package` retires packages which cause an
>  issue during an upgrade. We do nothing about all other retired
>  packages. Now imagine the following story (it already happened many
>  times):
>
>  We have package "foo". It is a leaf package. No one requires it. It
>  uses just basic libraries.
>  A user installs it during F32 lifetime.
>
>  Around F35 the upstream dies. Around F37 Fedora maintainer retires the
>  package (or orphan and it later become retired).
>
>  Because the package is a leaf package, it causes no pain during
>  upgrade F37->F38. Not even during upgrade to F39, F40, F41, F42. And
>  then during upgrade to F43 it suddenly causes a problem. But because
>  it is .fc37 everyone will hesitate to add it
>  fedora-obsolete-packages.fc43.
>
>  Additionally, during F38-F43, users may expect that their system is
>  fully updated and they have no security issues. But it is not true
>  about package "foo", which no one maintains. And users are not aware
>  of that because he does not follow fedora-devel mailing list.
>  Obviously.
>
>  What I propose is: As part of the retirement process we add the to
>  fedora-retired-packages:
>    Obsoletes: foo < %{latestversion+1}
>  And during upgrade from F37->F38 the package will be removed.
>
>  If the user wants to preserve the package (e.g., because it moved to
>  Copr), he simply uninstalls and protects the installation of
>  fedora-retired-packages. But that will be an informed decision.
>
>  The benefits are:
>   * we do not leave unmaintained packages on a user's machine.
>   * We make sure that archaic packages do not break upgrade between two
>  versions of Fedora.
>
>  == Feedback ==
>
>  After [https://bugzilla.redhat.com/show_bug.cgi?id=1816532#c5
>  discussion with fedora-obsolete-package maintainer] I filed this
>  Change proposal to include a wider audience.
>
>  See relevant
> [https://lists.fedoraproject.org/archives/list/[e-mail].o...
>  thread on devel mailing list].
>
>  == Benefit to Fedora ==
>   * We do not leave unmaintained packages on a user's machine.
>   * We make sure that archaic packages do not break upgrade between two
>  versions of Fedora.
>
>  == Scope ==
>  * Proposal owners:
>
>  Create package `fedora-retired-packages` as sub-package of
>  `fedora-obsolete-packages`
>  [https://bugzilla.redhat.com/show_bug.cgi?id=1816532 BZ#1816532]
>  Edit
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
>  guidelines with:
>
>  The retired package should be obsoleted by one of:
>
>   * fedora-obsoleted-packages - if the package can cause problem during
>  upgrade to next version of Fedora
>   * fedora-retired-packages - in all other cases
>
>  It is enough to open an issue on
>  https://src.fedoraproject.org/rpms/fedora-obsolete-packages
>
>  * Other developers:
>  No other work should be necessary.
>
>  * Release engineering:
>  This is optional. I may work with rel-eng to change
>  https://pagure.io/releng/blob/master/f/docs/source/sop_retire_orphaned_pa...
>  to automatically create PR for `fedora-obsolete-packages`
>
>  * Policies and guidelines: As stated above
>
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life#Obs...
>  will need an update.
>
>  * Trademark approval: N/A (not needed for this Change)
>
>
>  == Upgrade/compatibility impact ==
>  During an upgrade, all retired packages will be automatically removed.
>
>  User may opt-out by:
>  <pre>
>  $ cat /etc/dnf/dnf.conf
>  [main]
>  ...
>  exclude=fedora-retired-packages
>  </pre>
>
>
>  == How To Test ==
>  1. Upgrade to next version of Fedora.
>  2. Check all retired packages are removed.
>
>  == User Experience ==
>   - Packages that are no longer maintained are removed during a
>  distribution upgrade.
>
>  == Dependencies ==
>  This update has no dependencies on any other package.
>
>  == Contingency Plan ==
>  * Contingency mechanism: Drop `fedora-retired-package`. Or remove
>  `Obsoletes` from this sub-package.
>  * Contingency deadline: Beta freeze
>  * Blocks release? No
>
>  == Documentation ==
>  TBD
>
>  == Release Notes ==
>  TBD
>
>

[Till Hofmann]

On 6/16/20 1:16 AM, Miroslav Suchý wrote:
>  Dne 16. 06. 20 v 0:37 James Cassell napsal(a):
> > Please not using mechanism. Make it easy to opt out, or better yet opt-in.
>  
>  On package level, there is likely no other way. DNF team will have no time/resources to
> implement this on DNF level.
>  I can only thing of /usr/sbin/remove-retired-package which would be a wrapper for
>    dnf remove $list $of $retired $package
>  Does that sounds better?
>  
>  Is there some way how to get this information from PDC?
>  
> > Probably better to just advertise `yum list extras` which has existed since at least
> Fedora 12.
>  
>  Will be my mom able to write something like:
>   dnf remove $(dnf list extras | awk '{print $1} | grep -v
> "package-I-still-want")
>  ? 
FTR,
  dnf remove $(dnf repoquery --extras --exclude=package-I-still-want)
is the canonical way to do this (taken from dnf's manpage).

I agree that this is still not suitable for a regular user.

[Jiri Vanek]

On 6/15/20 10:43 PM, Solomon Peachy wrote:
>  On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
> > What I propose is: As part of the retirement process we add the to
> > fedora-retired-packages:
> >   Obsoletes: foo < %{latestversion+1}
> > And during upgrade from F37->F38 the package will be removed.
>  
>  Gah, no.  Just.. no.
>  
>  This will silently break otherwise-working software on production 
>  systems, and provide no straightforward way to get back to a working 
>  state. 
Not only production. An good example are games. They are dead for ages, and you still like
to play them.

As mentioned elsewhere, some dnf --find-unmaintaned-stuff can help here.
>  
> > If the user wants to preserve the package (e.g., because it moved to
> > Copr), he simply uninstalls and protects the installation of
> > fedora-retired-packages. But that will be an informed decision.
>  
>  So.. the package is dropped because it's not being maintained, yet.. 
>  it's being maintained in copr?  How often does this really happen?
>  
> > The benefits are:
> >  * we do not leave unmaintained packages on a user's machine.
>  
>  What about software installed from 3rd-party repositories?  What about 
>  packages that were downloaded and installed directly from ISVs?
>  
> >  * We make sure that archaic packages do not break upgrade between two
> > versions of Fedora.
>  
>  This is a laudable goal, but... surely a better approach is to improve 
>  the diagnostics when faced with upgrade failures?  That way the user 
>  will be able to make an informed choice at the time the problem would 
>  have occurred, rather than having the software (which they might be 
>  reliant upon) silently disappearing.
>  
>  I say this as someone who has run into this problem quite often over the 
>  years, including on the machine I'm using to write this email.  
>  Sometimes the correct solution is to remove the old package, but other 
>  times that package is in active use.
>  
>  
>   - Solomon
>  
>  
>  _______________________________________________
>  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]
>   

-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com    M: [phone]

[Kevin Kofler]

Kamil Paral wrote:
>  I'll not talk about implementation, there are more suitable
> people for
>  that here. But I'll voice my opinion that automatically retiring software
>  from Fedora users' computers is a sane and proper thing to do. If a
>  package is removed from Fedora, it should also be removed from users
>  computers (during FN+1 upgrade). Of course, we should allow users to keep
>  it, if they want it. But the default process should happen automatically,
>  and users should opt-out of automatic retiring, instead of opt-in. Only
>  this way we can build a secure and reliable operating system.
>  
>  If only power users can opt-out from retiring a package (e.g. by editing
>  dnf.conf), I don't think that's a problem. Because even though general
>  users will of course be unhappy when an application they use get
>  permanently removed during system upgrade, they will be even more unhappy
>  when their system suddenly breaks in the future, either by unresolved
>  dependencies, or when the retired app/library causes the system to not
>  boot or breaks the desktop, because nobody at that points expects and
>  tests those software interactions. A general user can resolve a missing
>  app, but they can't resolve a broken OS. If they want to deviate from the
>  system we provide, it's reasonable to ask them to have certain technical
>  knowledge, instead of allowing them to shoot themselves in the foot (even
>  unknowingly, by not doing automatic retirement). 
I cannot agree with these statements. I think removing working software from 
users' systems is not something we should ever do. I see it as inherently 
incompatible with our "Freedom" principle (what happened to Freedom 0, the 
right to run the software?), and also with "Features" (as removing an 
application obviously removes its features). And it surely will not make you 
any "Friends" either.

        Kevin Kofler

[Robbie Harwood]

Miroslav Suchý <msuchy(a)redhat.com&gt; writes:

>  Will be my mom able to write something like:
>   dnf remove $(dnf list extras | awk '{print $1} | grep -v
> "package-I-still-want")
>  ? 
Quite possibly.  It is safe to say most of us do not know your mother;
while your mother may be not versed in scripting, plenty of mothers are.

To be clear: I'm sure you had only the best intentions and are speaking
only about your own parent.  However, this kind of example (non-male
assumed to not understand technology) does not foster inclusion (instead
furthering a sexist stereotype).

Some phrases that can be used instead: "a regular user" (what Till
used), "nontechnical user", "non-programmer friend", "a Linux
newcomer",
"the average user", etc..

Hope that helps.

Thanks,
--Robbie

[Kamil Paral]

On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler <kevin.kofler(a)chello.at&gt;
wrote:

>  Kamil Paral wrote:
>  > I'll not talk about implementation, there are more suitable people for
>  > that here. But I'll voice my opinion that automatically retiring software
>  > from Fedora users' computers is a sane and proper thing to do. If a
>  > package is removed from Fedora, it should also be removed from users
>  > computers (during FN+1 upgrade). Of course, we should allow users to keep
>  > it, if they want it. But the default process should happen automatically,
>  > and users should opt-out of automatic retiring, instead of opt-in. Only
>  > this way we can build a secure and reliable operating system.
>  >
>  > If only power users can opt-out from retiring a package (e.g. by editing
>  > dnf.conf), I don't think that's a problem. Because even though general
>  > users will of course be unhappy when an application they use get
>  > permanently removed during system upgrade, they will be even more unhappy
>  > when their system suddenly breaks in the future, either by unresolved
>  > dependencies, or when the retired app/library causes the system to not
>  > boot or breaks the desktop, because nobody at that points expects and
>  > tests those software interactions. A general user can resolve a missing
>  > app, but they can't resolve a broken OS. If they want to deviate from the
>  > system we provide, it's reasonable to ask them to have certain technical
>  > knowledge, instead of allowing them to shoot themselves in the foot (even
>  > unknowingly, by not doing automatic retirement).
>
>  I cannot agree with these statements. I think removing working software
>  from
>  
You can't say whether it's working, because it has been retired in Fedora,
it has no maintainer, no testing, no security updates or bug fixes.


>  users' systems is not something we should ever do. I see it as
> inherently
>  incompatible with our "Freedom" principle (what happened to Freedom 0, the
>  right to run the software?), 

Your freedom is unchanged, you can still do whatever you want with your
system. You can opt out of any process and behavior in Fedora, because full
sources are available. And not only that, we will have a way for power
users to easily opt-out. We might even have a way for general users to
opt-out, if we go the extra mile (but the extra mile is not necessary for
the purpose of this proposal, in my eyes).


>  and also with "Features" (as removing an
>  application obviously removes its features). 

That principle doesn't say that no features will ever be removed.


>  And it surely will not make you
>  any "Friends" either.
>  
Nor will broken systems or systems infected by malware because of security
flaws. The user has freedom to ignore any of our workflows, but the
defaults should be well-maintained and safe.

I'd like Fedora systems to be transparent and honest. If some packages need
to be removed, tell me about it, and ideally also tell me why (e.g. no
longer maintained). If possible, tell me how to avoid it temporarily (it
might be months or years, but unmaintained software will break one day
unexpectedly), but be clear about the consequences. For general users, this
information might involve just "important" packages (not libraries etc) -
we don't do this well at present.
This approach beats "never ever removing anything, at any cost", at least
for me.

[Neal Gompa]

On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`.
>  
This whole process is unnecessary. You're basically asking for
autoremove behavior to occur as part of a distro-sync action. This
boils down to an RFE to the DNF team to extend the distro-sync action
used by system-upgrade to optionally be able to do autoremove at the
same time, and make the system-upgrade plugin actually *do* that by
default.

Let's focus on doing it that way, instead.




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

[Christopher Engelhard]

I can't speak to the implementation of this, but I am in favour of the
approach in general, with one caveat: I think it is important to
implement this in a way that makes it possible for users to keep
*individual* retired packages around. Blacklisting
fedora-retired-packages is too broad a brush from the user perspective,
and will make it much harder to identify problems.

A question regarding this: What would happen if an update to
fedora-retired-packages obsoletes a package that is present on my system
but listed in dnf's excludepkgs?

Christopher

[Jiří Eischmann]

Kamil Paral píše v Út 16. 06. 2020 v 14:21 +0200:
>  On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler
> <kevin.kofler(a)chello.at
>  > wrote:
>  > Kamil Paral wrote:
>  > > I'll not talk about implementation, there are more suitable
>  > people for
>  > > that here. But I'll voice my opinion that automatically retiring
>  > software
>  > > from Fedora users' computers is a sane and proper thing to do. If
>  > a
>  > > package is removed from Fedora, it should also be removed from
>  > users
>  > > computers (during FN+1 upgrade). Of course, we should allow users
>  > to keep
>  > > it, if they want it. But the default process should happen
>  > automatically,
>  > > and users should opt-out of automatic retiring, instead of opt-
>  > in. Only
>  > > this way we can build a secure and reliable operating system.
>  > > 
>  > > If only power users can opt-out from retiring a package (e.g. by
>  > editing
>  > > dnf.conf), I don't think that's a problem. Because even though
>  > general
>  > > users will of course be unhappy when an application they use get
>  > > permanently removed during system upgrade, they will be even more
>  > unhappy
>  > > when their system suddenly breaks in the future, either by
>  > unresolved
>  > > dependencies, or when the retired app/library causes the system
>  > to not
>  > > boot or breaks the desktop, because nobody at that points expects
>  > and
>  > > tests those software interactions. A general user can resolve a
>  > missing
>  > > app, but they can't resolve a broken OS. If they want to deviate
>  > from the
>  > > system we provide, it's reasonable to ask them to have certain
>  > technical
>  > > knowledge, instead of allowing them to shoot themselves in the
>  > foot (even
>  > > unknowingly, by not doing automatic retirement).
>  > 
>  > I cannot agree with these statements. I think removing working
>  > software from 
>  
>  You can't say whether it's working, because it has been retired in
>  Fedora, it has no maintainer, no testing, no security updates or bug
>  fixes. 
+1
Any software which doesn't get maintenance at least on the security
level should be considered by any responsible software provider as
broken these days.

I'd also add that it creates confusion among users. I often read
questions on forums like: "I've got a package XY on my computer with
Fedora 32 upgraded from a previous version, but I cannot install the
same package on a freshly installed Fedora 32. Why?"

Jiri

[Solomon Peachy]

On Tue, Jun 16, 2020 at 02:21:27PM +0200, Kamil Paral wrote:
>  You can't say whether it's working, because it has been
> retired in Fedora,
>  it has no maintainer, no testing, no security updates or bug fixes. 
"Retired" means it has no maintainer willing to fix a package build 
error, nothing more.  It does not imply the package has been tested, or 
is receiving any sort of bug fixes or security updates.

(I can provide counterexamples of "maintained" packages in Fedora that 
 simply *did not work*, for *multiple releases*.  But it packaged 
 cleanly, so it got shipped.)

Only the final user can determine if they need a specific package or 
not.  Indeed, being installed is a pretty good indication that the user 
actually wanted it.  Do they still want it?  Only they can answer that.

Under no circumstances is it okay to remove a package without being VERY 
EXPLICIT that it is being removed due to it blocking an upgrade.

(In the past, and indeed today, this explicit user consent on upgrades 
 is required, in the form of manually removing the offending package or 
 passing --allowerasing on the DNF command line)

>  Nor will broken systems or systems infected by malware because of
> security
>  flaws. The user has freedom to ignore any of our workflows, but the
>  defaults should be well-maintained and safe. 
"Safe" also means "don't do things the user doesn't expect."

Auto-removing software is a *significant* change in user-visible 
behavior, and it's the non-powerusers that will be the ones impacted the 
most.

>  I'd like Fedora systems to be transparent and honest. If some
> packages need
>  to be removed, tell me about it, and ideally also tell me why (e.g. no
>  longer maintained).  
Not "ideally", "must" -- because you never, never, never remove stuff

without expliclt user consent, and the user can't meaningfully consent 
if they're not given enough information to make that determination.

This distinction is crucial -- packages being "removed" is not just part 
of every 'dnf system-upgrade' I've ever done, but also nearly every 
routine 'dnf update' (kernel packages are added/removed, not 
"upgraded").  

And that's the cmdline view; if folks use the GUI tools (ie most users) 
only "updated" packages are shown in the details, not stuff that's being 
added or removed.  How exactly is the user supposed to be informed?

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[Miroslav Suchý]

Dne 16. 06. 20 v 9:56 Vít Ondruch napsal(a):
>  1) It does not reflect, that this is not just about retired
> packages,
>  but also (or mainly?) about subpackages, which we don't retire.
>  
>  2) The point (1) is closely related to -debuginfo packages topic [1]
>  which I re-raised recently with not as much attention as I would like. 
Both points are valid and good examples. Noted. Thank you.

>  Also, I wonder what is wrong with "dnf autoremove", which
> is supposed to
>  remove unused leaf packages, which were not explicitly installed? 
On my system it does not want to remove fwupdate-libs.fc29. Hmm, it seems that it ignores
anything else than fc32 (on my
F32 machine).

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

[Jóhann B. Guðmundsson]

On 16.6.2020 12:21, Kamil Paral wrote:
>  I'd like Fedora systems to be transparent and honest. If some packages 
>  need to be removed, tell me about it, and ideally also tell me why 
>  (e.g. no longer maintained). If possible, tell me how to avoid it 
>  temporarily (it might be months or years, but unmaintained software 
>  will break one day unexpectedly), but be clear about the consequences. 
>  For general users, this information might involve just "important" 
>  packages (not libraries etc) - we don't do this well at present.
>  This approach beats "never ever removing anything, at any cost", at 
>  least for me. 
I whole heartedly agree with your take on this but Kevin concerns are valid.

Based on my experience pushing Fedora as an Fedora ambassador to novice 
end users ( subsequently having to install/setup/and support their 
installation as a result of that ), it was enough for the desktop team 
to rearrange locations of apps in menus to scare novice end users away 
from *using* Linux ( yes not just Fedora but Linux altogether ) and them 
wanting to use windows or os-x again, something that they were 
*familiar* with and did not constantly keep changing ( which is why 
Microsoft had to reluctantly keep the old look and feel of Windows ) And 
I know first hand that the Gnome community in Fedora has never gotten 
this right because seemingly trivial changes like tidying up menu's are 
huge changes to the novice end users that operate on familiar look and 
"click here" memory.

To me this is a question of what is Fedora target audience.

It cant be novice end users since those cant install Fedora and afaik 
people cant buy hw with Fedora pre-installed and even if that option was 
available for the novice end users you would have to be a pretty good 
sales person to convince them to abandon something they are familiar 
with ( talking from a first hand experience doing exactly that ) as in 
windows or os-x. ( Arguably there always has been and still is the 
underlying expectation that Fedora users are atleast somewhat familiar 
with Linux and RHEL, basically RHEL administrators I would say )

This is also a question of what constitutes as an "unmaintained 
software" in the distribution. Is it dead upstream, is it awol package 
maintainer, is it poorly maintained packages like the maintainer that 
only appears when there is a pending RHEL release then disappears, is it 
not responding to bugs filed against his or her component etc.

But the act of removing an unmaintained application/package in the 
distribution wont scare people away from using Fedora no more than ( 
even trivial by every count ) changes that the Gnome community has 
historically done in the distribution thus a less of an issue that Kevin 
makes it out to be and leaving something installed on end users system 
can do more harm than good I would say.

Presumably this is also less of an issue as end users stop installing 
application from the distribution but instead do so with flatpaks and at 
one point application will no longer be provided in the distribution ( 
you have to install it from flatpak marketplace).

Just my 2 cents.

JBG

[Gary Buhrmaster]

On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`.
>  
I am in favor of the intention that when you upgrade,
those packages from previous releases are removed
automagically.  After an upgrade I typically expect
the system and packages to be supported and
maintained in the same way as if I installed new.

And if I need some package that is no longer in
Fedora, I will build it for my personal or organizational
use and accept the additional support burden
explicitly and not by accident (and I often start by
leveraging the old .src rpms from Fedora).

FD: I spend time after every upgrade to remove old
retired packages, and not having to doing so would
make life easier.

[Solomon Peachy]

On Tue, Jun 16, 2020 at 05:15:37PM +0000, Gary Buhrmaster wrote:
>  I am in favor of the intention that when you upgrade,
>  those packages from previous releases are removed
>  automagically.  
How will you know it is going away?  When you discover the software 
missing post-upgrade?

>  After an upgrade I typically expect
>  the system and packages to be supported and
>  maintained in the same way as if I installed new. 
User/Admin customizations are expected to be retained post-upgrade, and 
software installed after the fact absolutely counts as a customization, 
no matter where that software came from.

I'm talking about stuff that got installed because the user explicitly 
asked for it, not because it got pulled in as a dependency.

And what about non-Fedora software?  That can break an upgrade too, are 
we going to automagically remove that stuff too?  If not, Fedora will 
still going to have to handle those upgrade failures gracefully.

>  FD: I spend time after every upgrade to remove old
>  retired packages, and not having to doing so would
>  make life easier. 
I spend time before every upgrade enumerating the things that are 
expected to break in the upgrade, and tackling those issues pre-upgrade 
or staging things so I can do it post-upgrade.  Getting the list of 
packages that triggere pre-upgrade failures is a big help in that regard.

After every upgrade, as well as tackling the known breakages, I also 
have to deal with the stuff that unexpectedly broke.  Which, to Fedora's 
credit, is pretty rare these days.

But.  I cannot strongly object enough to automatically uninstalling a 
package solely because it was retired, because "retired" does not mean 
"broken".

A reasonable argument for automagic removal can be made for packages 
that will break due to an unmet dependency, but ultimately the user is 
the only one who can determine if proceeding is okay or not.  And to 
determine that, they need to be suitably informed.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[Gerald Henriksen]

On Tue, 16 Jun 2020 15:05:41 -0400, you wrote:

> User/Admin customizations are expected to be retained post-upgrade,
> and 
> software installed after the fact absolutely counts as a customization, 
> no matter where that software came from. 
But any software installed by the user that comes from an official
Fedora repo is installed on the assumption that it is being maintained
by Fedora - that is why it is in the Fedora repo.

If the software is no longer being maintained (either due to a lack of
a packager, or because upstream has disappeared) that implied contract
is no longer true.

> And what about non-Fedora software?  That can break an upgrade too,
> are 
> we going to automagically remove that stuff too?  If not, Fedora will 
> still going to have to handle those upgrade failures gracefully. 
Any software installed from non-Fedora sources will involve a decision
by the user to accept that it is not being supported by Fedora.

This should (although sadly likely doesn't) mean that the user pays
attention as to whether the software is being updated and supported or
not.

> But.  I cannot strongly object enough to automatically uninstalling a
>
> package solely because it was retired, because "retired" does not mean 
> "broken". 
Given the number of cases of evil people getting access to computer
systems, and the fallout of said attacks, any package left on a system
after it no longer is being maintained is not only broken but a
security risk.

You as a user may wish to explicitly make the decision to ignore that
risk and keep or re-install that software, and that is your choice.
But it should not be the default behaviour of the distribution.

[Jonathan Wakely]

On 16/06/20 02:24 +0200, Kevin Kofler wrote:
> Ben Cotton wrote:
> > == Summary ==
> > All retired packages are obsoleted by `fedora-retired-packages`.
> >
> > == Owner ==
> > * Name: [[User:msuchy| Miroslav Suchý]]
> > * Email: msuchy(a)redhat.com
>
> Absolute -1!
>
> IMHO, removing working packages from users' systems just because the new
> release no longer ships them is entirely unnecessary and a total disservice
> to users.
>
> > == Upgrade/compatibility impact ==
> > During an upgrade, all retired packages will be automatically removed.
> >
> > User may opt-out by:
> > <pre>
> > $ cat /etc/dnf/dnf.conf
> > [main]
> > ...
> > exclude=fedora-retired-packages
> > </pre>
>
> Is this actually honored by all tools, including PackageKit? (Last I
> checked, PackageKit ignored dnf.conf entirely.) The opt-out needs to work
> with PackageKit to be of any use. 
It works with PK now:
https://bugzilla.redhat.com/show_bug.cgi?id=1338975#c5

[Jóhann B. Guðmundsson]

On 16.6.2020 20:22, Gerald Henriksen wrote:
>  Given the number of cases of evil people getting access to computer
>  systems, and the fallout of said attacks, any package left on a system
>  after it no longer is being maintained is not only broken but a
>  security risk. 
Unless the process and the approach of "If it builds let's ship it" has 
not been changed over the years then the end user might be getting a 
package that is not actually being maintained in the distribution thus 
already is a security risk ( without it being flagged retired ) to begin 
with so arguably that problem needs to be solved first or at the same 
time as this.

I think people first need to establish what perception and thus meaning 
people put in the words retired,broken,maintained etc. before the proper 
course of action can be taken.

JBG

[Solomon Peachy]

On Tue, Jun 16, 2020 at 04:22:42PM -0400, Gerald Henriksen wrote:
>  Given the number of cases of evil people getting access to computer
>  systems, and the fallout of said attacks, any package left on a system
>  after it no longer is being maintained is not only broken but a
>  security risk. 
"no longer packaged by fedora" is not the same as being "broken" or 
"insecure".  Just as "packaged by fedora" doesn't mean that it
works or 
is kept secure.  So please, please do not conflate the two.

(Case in point: dokuwiki, which was only "secure" in the sense that it 
 was completely broken for 2-3 fedora releases, so exploiting the 
 multiple outstanding CVEs in the packaged version was impossible..)

"Security" is a process, not a state; it has to be balanced against 
"usability"

What good is a security policy that requires me to disable it to 
continue using software that I find necessary?  Or worse, a policy that 
auto-removes software I might still be using?  That is actively 
user-hostile, and you'll rapidly see instructions on how to disable it 
crop up on the inevitable "how to make your fedora system usable" 
instructions.  Right after "disable selinux" but before "enable 
freshrpms", "install google chrome", and the inevitable "sudo curl 
http://github.com/blabla | bash" at the end.

Meanwhile, let's be honest.  Is my main server more likely to get 
compromised through my use of mailgraph (dead upstream for over a decade 
and retired after F29 because nobody bothered to fix its selinux 
integration) or because one of my users had a shared password 
compromised in $massive_data_breach_du_jour?

>  You as a user may wish to explicitly make the decision to ignore
> that
>  risk and keep or re-install that software, and that is your choice.
>  But it should not be the default behaviour of the distribution. 
"Fedora knows better than its users" represents a massive shift in 
Fedora policy, and should be discussed as such before anyone talks about 
how to implement it.

If Fedora drops a package, that package currently gets relegated to the 
same position as any other software the user installed from non-Fedora 
sources -- which I'd wager is the overwhelming majority of 
workstation-type installs and a significant chunk of server-type 
installs too.

Upgrades still have to handle non-Fedora-supplied packages sanely, and 
the only sane, user-friendly way to handle those is to inform the user 
of the issue and let them decide what to do.  On a per-package basis, 
because no matter what the default is, it's going to be wrong when 
applied across the board.

(Of the dozen-ish Fedora installs I'm responsible for, exactly one would 
 be fine with this new policy.  Every other one, workstation and server 
 alike, is a special snowflake. Folks not running snowflake systems 
 don't do in-place OS upgrades; they spin up new instances from scratch)

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[Solomon Peachy]

On Tue, Jun 16, 2020 at 08:49:57PM +0000, Jóhann B. Guðmundsson wrote:
>  Unless the process and the approach of "If it builds let's
> ship it" 
>  has not been changed over the years then the end user might be getting 
>  a package that is not actually being maintained in the distribution 
>  thus already is a security risk ( without it being flagged retired ) 
>  to begin with so arguably that problem needs to be solved first or at 
>  the same time as this. 
Exactly!

Nearly every webapp packaged by Fedora is in this boat.

Dokuwiki was a particularly aggregious example; the packaged version was 
completely *broken* between F25 and late-F28, incompatible with the PHP7 
interpreter that Fedora shipped in those releases.

That incompatibility was a blessing of sorts, as it also meant that 
between F25 and late-F28, the multiple CVEs present in that package 
weren't exploitable.

(I actually reported this brokenness in F25.  That ticket ended up being 
 auto-closed when F27 came out, without the package getting fixed...)

>  I think people first need to establish what perception and thus
> meaning
>  people put in the words retired,broken,maintained etc. before the proper
>  course of action can be taken. 
"retired" tells you nothing more than "no longer packaged".

"packaged" does not mean "maintained by fedora".  It certianly
doesn't 
mean "kept up to date with upstream releases" or "kept updated with 
security fixes"

And "broken" in this context means nothing more than "failed to 
package/build", because "packaged" doesn't mean "it actually 
works/runs".

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[Jóhann B. Guðmundsson]

On 16.6.2020 21:44, Solomon Peachy wrote:
>  "retired" tells you nothing more than "no longer
> packaged".
>
>  "packaged" does not mean "maintained by fedora".  It certianly
> doesn't
>  mean "kept up to date with upstream releases" or "kept updated with
>  security fixes"
>
>  And "broken" in this context means nothing more than "failed to
>  package/build", because "packaged" doesn't mean "it actually
>  works/runs". 
The solution to this problem should be quite evident and that is to 
archive the "retired" components as flatpaks ( if the component is a 
desktop app ) or a as container ( if it's a server application or 
application stack ) using OCI Images and the OCI distribution mechanism 
as a deployment technology( for organization ) that is if the 
application or application stack is of any real, practical or nostalgic 
value to end users or organization which would be worth keeping.

That approach should solve both the package management issues and "if it 
ain’t broken, don’t touch it" or simply keeping it available because 
it's useful to some end user(s) dilemma along with bunch of other 
problems that affect Fedora but people seem to be expecting different 
results using the same old thinking, which lead to the same old 
approaches, to solve the same old problems.

JBG

[Till Hofmann]

On 6/16/20 9:56 AM, Vít Ondruch wrote:
>  Also, I wonder what is wrong with "dnf autoremove", which
> is supposed to
>  remove unused leaf packages, which were not explicitly installed? 
On my system, it removed grub2-efi and made the system unbootable. So
I'm not sure running this as part of the system upgrade would be a good
idea.

[I'll dig into this and see if I need to file a bug]

Kind regards,
Till

[Kamil Paral]

On Tue, Jun 16, 2020 at 2:30 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton <bcotton(a)redhat.com&gt;
> wrote:
>  >
>  > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>  >
>  > == Summary ==
>  > All retired packages are obsoleted by `fedora-retired-packages`.
>  >
>
>  This whole process is unnecessary. You're basically asking for
>  autoremove behavior to occur as part of a distro-sync action. 

Autoremove only removes leaf packages which were installed as dependencies
of user-installed packages, but are no longer required. So it is a
completely different thing and is not applicable in this case.

[Vít Ondruch]

Dne 17. 06. 20 v 9:15 Till Hofmann napsal(a):
>  On 6/16/20 9:56 AM, Vít Ondruch wrote:
> > Also, I wonder what is wrong with "dnf autoremove", which is supposed to
> > remove unused leaf packages, which were not explicitly installed?
>  On my system, it removed grub2-efi and made the system unbootable. So
>  I'm not sure running this as part of the system upgrade would be a good
>  idea.
>
>  [I'll dig into this and see if I need to file a bug] 

Thx, fixing issues like this is what we should aim at. I myself noticed
several times some package like (or maybe precisely this package)
grub2-efi was removed, but my system was always fine after that.

I know that several times, I had to use "dnf mark install" to prevent
some package from being removed, because I knew I want such package. So
there are definitely some gaps, but we should fix them. I am afraid that
neither `fedora-retired-packages` will ask you for not removing some
package.


Vít


>  Kind regards,
>  Till
>  _______________________________________________
>  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]

[Vít Ondruch]

Dne 16. 06. 20 v 14:38 Christopher Engelhard napsal(a):
>  I can't speak to the implementation of this, but I am in favour
> of the
>  approach in general, with one caveat: I think it is important to
>  implement this in a way that makes it possible for users to keep
>  *individual* retired packages around. Blacklisting
>  fedora-retired-packages is too broad a brush from the user perspective,
>  and will make it much harder to identify problems. 

Do we have weak obsoletes? :)


Vít


>  A question regarding this: What would happen if an update to
>  fedora-retired-packages obsoletes a package that is present on my system
>  but listed in dnf's excludepkgs?
>
>  Christopher
>  _______________________________________________
>  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]

[Solomon Peachy]

On Tue, Jun 16, 2020 at 10:23:30PM +0000, Jóhann B. Guðmundsson wrote:
>  The solution to this problem should be quite evident and that is to
> archive
>  the "retired" components as flatpaks ( if the component is a desktop app )
>  or a as container ( if it's a server application or application stack ) 
This will require a ton of work from maintainers, which is funny as the 
main reason this discussion has come up is because maintainers don't 
have the time/bandwidth to, well, maintain things.

And to top it all off, won't really work for many/most packages, becasue 
they are components, not self-contained/standalone applications.

Take my mailgraph example; how exactly is that supposed to work as a 
standalone flatpak or container?  It's a component of some larger system 
rather than a standalone application useful in its own right.

(It requires access to /var/log/mail, maintains its own data store via 
 rrdtool, and generates files intended to be served via an external http 
 process)

Yes, mailgraph could be suitably munged to work within flatpak/container 
scope restrictions, but if there was maintainer bandwidth to do that, it 
wouldn't have been retired in the first place.

Meanwhile, what about retired libraries?  How exactly is a flatpack or 
container going to help folks continue to use them?

By the time you devise a way to bundle up all of these retired packages 
in a way that they remain useful to all possible use-cases... you'll end 
up with this meta-container thing of disparate, optionally-installable 
software that's sorta configured to generally work together.  I know, we 
can call this thing "An Older Fedora Linux Distribution"

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

[John M. Harris Jr]

On Monday, June 15, 2020 5:24:54 PM MST Kevin Kofler wrote:
>  Ben Cotton wrote:
>  
>  > == Summary ==
>  > All retired packages are obsoleted by `fedora-retired-packages`.
>  > 
>  > == Owner ==
>  > * Name: [[User:msuchy| Miroslav Suchý]]
>  > * Email: msuchy(a)redhat.com
>  
>  
>  Absolute -1!
>  
>  IMHO, removing working packages from users' systems just because the new 
>  release no longer ships them is entirely unnecessary and a total disservice
>   to users. 
Agreed, this Change would irrecoverably harm users' systems upon an upgrade, 
entirely unnecessarily.

-- 
John M. Harris, Jr.

[Miroslav Suchý]

Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
>  https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
>  
>  == Summary ==
>  All retired packages are obsoleted by `fedora-retired-packages`. 
I am moving back this proposal.

I want to thank all of you for the feedback. I was surprised by lots of reactions standing
against automatic removal of
packages which are not maintained any more. At the same time, I respect your voice.
Therefore I take back this proposal and I will replace the proposal by different one. A
tool which will give user a list
of packages that can/should be removed.

As this tool will need some coding, it is unlikely that I will do that in F33 timeframe.
You may expect it for F34.

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

[Neal Gompa]

On 6/23/20, Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:
>  Dne 15. 06. 20 v 21:47 Ben Cotton napsal(a):
> > https://fedoraproject.org/wiki/Changes/Fedora-Retired-Packages
> >
> > == Summary ==
> > All retired packages are obsoleted by `fedora-retired-packages`.
>
>  I am moving back this proposal.
>
>  I want to thank all of you for the feedback. I was surprised by lots of
>  reactions standing against automatic removal of
>  packages which are not maintained any more. At the same time, I respect your
>  voice.
>  Therefore I take back this proposal and I will replace the proposal by
>  different one. A tool which will give user a list
>  of packages that can/should be removed.
>
>  As this tool will need some coding, it is unlikely that I will do that in
>  F33 timeframe. You may expect it for F34.
>  
That sounds good to me. :)


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

[Vitaly Zaitsev]

On 23.06.2020 10:39, Miroslav Suchý wrote:
>  A tool which will give user a list of packages that can/should be
> removed. 
dnf -C list extras

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

[Przemek Klosowski]

On 6/23/20 5:35 AM, Vitaly Zaitsev via devel wrote:
>  On 23.06.2020 10:39, Miroslav Suchý wrote:
> > A tool which will give user a list of packages that can/should be removed.
>  dnf -C list extras 
Nice, thanks for finding this --- but it also lists all the 
debugsource/debuginfo packages, and for some reason kmod-wireguard



>

[Vitaly Zaitsev]

On 24.06.2020 04:40, Przemek Klosowski via devel wrote:
>  Nice, thanks for finding this --- but it also lists all the
> debugsource/debuginfo packages 
This is intended, because debug repositories are disabled by default and
these packages does not belongs to any repositories.

You can run `sudo dnf list extras --enablerepo=\*debug` to include them.

>  and for some reason kmod-wireguard 
Btw, WireGuard is a part of Linux kernel since 5.6.0. You should remove
this package.

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

[Przemek Klosowski]

On 6/24/20 5:51 AM, Vitaly Zaitsev via devel wrote:
>  On 24.06.2020 04:40, Przemek Klosowski via devel wrote:
> > Nice, thanks for finding this --- but it also lists all the debugsource/debuginfo
> packages
>  This is intended, because debug repositories are disabled by default and
>  these packages does not belongs to any repositories.
>
>  You can run `sudo dnf list extras --enablerepo=\*debug` to include them. 
dnf list extras --enablerepo=\*debuginfo

Why did you sudo it? It seems to work from a regular account just fine.

[Vitaly Zaitsev]

On 24.06.2020 22:16, Przemek Klosowski via devel wrote:
>  Why did you sudo it? It seems to work from a regular account just
> fine. 
Without sudo or `-C` command-line option dnf will download copies of all
repository metadata to your home directory. I don't like such behavior.

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

[Miroslav Suchý]

Dne 24. 06. 20 v 4:40 Przemek Klosowski via devel napsal(a):
>  dnf -C list extras 
How do I skip packages which are installed from @@commandline? Is there anything else than
"grep -v"?

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

[Jaroslav Mracek]

On Thu, Jun 25, 2020 at 9:09 PM Miroslav Suchý <msuchy(a)redhat.com&gt; wrote:

>  Dne 24. 06. 20 v 4:40 Przemek Klosowski via devel napsal(a):
>  > dnf -C list extras
>
>  How do I skip packages which are installed from @@commandline? Is there
>  anything else than "grep -v"?
>
>  
I am sorry but this is not an easy task with DNF CLI and too specific.
`grep` would be the best option. Or you can set up your own script using
DNF API. I can help with that.

Jasroslav