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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
>
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek@xxxxxxxxxx M: +420775390109
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
