On Tue, Oct 4, 2016 at 9:09 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:
> On Oct 4, 2016 8:52 AM, "Adam Williamson" <adamwill(a)fedoraproject.org
> <mailto:email@example.com>> wrote:
>> Recently several reports of people getting 'duplicated packages' and
>> 'kernel updates not working' have come through to us in QA from Fedora
>> 24 users. I managed to get one reporter to explain more specifically
>> what happened, and it sounds a lot like what's happening is that
>> something in the 'dnf update' process can cause a GNOME or X crash,
>> possibly depending on hardware or package set installed. When that
>> happens, the update process is killed and does not complete cleanly,
>> which is why you get 'duplicated packages' and other odd results.
> How hard would it be to make dnf do the rpm transaction inside a proper
> system-level service (transient or otherwise)? This would greatly increase
> robustness against desktop crashes, ssh connection loss, KillUserProcs, and
> other damaging goofs.
That seems like a waste of effort, considering we have the offline updates
process which just boots into a special, minimalist environment with almost
nothing but the updater running.
By that standard, why do we support dnf at all?
$ sudo dnf upgrade
Error: dnf upgrade is dangerous. Use PackageKit instead and reboot when asked.
I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks. As far as I know, Fedora
considers plain ol' dnf to be supported.
For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.