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/devel@lists.fedoraproject.org
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109