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@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/devel@lists.fedoraproject.org/... 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#Obsole... 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_packa... 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#Obsole... 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
-----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@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/devel@lists.fedoraproject.org/... 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#Obsole... 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_packa... 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#Obsole... 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 ==
- Upgrade to next version of Fedora.
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
- -- Igor Raits ignatenkobrain@fedoraproject.org
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.
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
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.
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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 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
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
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.
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.
Miroslav Suchý msuchy@redhat.com 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
...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/devel@lists.fedoraproject.org/... 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#Obsole... 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_packa... 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#Obsole... 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
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
Ben Cotton wrote:
== Summary == All retired packages are obsoleted by `fedora-retired-packages`.
== Owner ==
- Name: [[User:msuchy| Miroslav Suchý]]
- Email: msuchy@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
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@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
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@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.
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.
On Mon, Jun 15, 2020 at 9:50 PM Ben Cotton bcotton@redhat.com 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).
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
On Tue, Jun 16, 2020 at 12:25 PM Kevin Kofler kevin.kofler@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.
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.
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@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
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
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
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/devel@lists.fedoraproject.org/...
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@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/devel@lists.fedoraproject.org/... 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#Obsole... 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_packa... 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#Obsole... 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 ==
- Upgrade to next version of Fedora.
- 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
Dne 16. 06. 20 v 9:56 Vít Ondruch napsal(a):
- It does not reflect, that this is not just about retired packages,
but also (or mainly?) about subpackages, which we don't retire.
- 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).
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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton bcotton@redhat.com 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!
On Tue, Jun 16, 2020 at 2:30 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 15, 2020 at 3:48 PM Ben Cotton bcotton@redhat.com 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.
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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Jun 15, 2020 at 7:48 PM Ben Cotton bcotton@redhat.com 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.
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
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.
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
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
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
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
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
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.
On 6/23/20, Miroslav Suchý msuchy@redhat.com 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. :)
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
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.
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.
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.
On Thu, Jun 25, 2020 at 9:09 PM Miroslav Suchý msuchy@redhat.com 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
-
Ben Cotton -
Christopher Engelhard -
Gary Buhrmaster -
Gerald Henriksen -
Ian McInerney -
Igor Raits -
James Cassell -
Jaroslav Mracek -
Jiri Vanek -
Jiří Eischmann -
John M. Harris Jr -
Jonathan Wakely -
Jóhann B. Guðmundsson -
Kamil Paral -
Kevin Fenzi -
Kevin Kofler -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Przemek Klosowski -
Robbie Harwood -
Solomon Peachy -
Till Hofmann -
Vitaly Zaitsev -
Vít Ondruch