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