Re: PackageKit cleanup: Do you use these functions?
2014-09-12 1:49 GMT+02:00 Cameron Norman <camerontnorman@gmail.com>:
> El mié, 10 de sep 2014 a las 5:34 , Matthias Klumpp <matthias@tenstral.net>
> escribió:
>> [...]
>
> What are the options?
>
> I would like if apps could say somehow (maybe an extension to the AppStream
> format?) whether they need offline updates, or if online is fine, so that it
> is only when needed. Also, an option to ignore apps' preferences and just do
> always offline or always online should be present (in PK's configuration).
That would probably be an overkill, although details like that could
theoretically be stored in the AppStream/DEP-11 metadata.
> Is this how the feature has been implemented? Do you think upstream (and you
> as an AppStream supporter / developer) would be enthusiastic about adding
> this, if it is not the status quo?
Possible, but unlikely - I don't think it's needed.
Here is a brief explanation about what actually happens when
"offline-updates" are enabled:
the online-updaters will work as always, even PackageKit is able to
perform online-updates like it always did. But if a desktop like GNOME
(and I am really only talking about desktops here) recognizes updates,
it will tell PackageKit to download updates locally. Whan that is
done, the user is notified about available updates (and might be asked
for reboot), or the shutdown button simple gets an "reboot & update"
sign.
Now, if the user reboots, the system enters a special mode where
updates are installed using PK (progress is shown on Plymouth), then
it reboots again and enters the desktop.
Now, in case an offline-update was prepared and the user does an
online-update, the "reboot & install updates" sign will simply vanish,
and everything will behave like it always did.
This feature is meant for unexperienced users, so, as Steve pointed
out, it would have to be default - but even if it was, it would be
pretty non-invasive.
Currently, GNOME-Software makes heavy use of offline-updates, and I
don't know of anything else which does (except for the cli tools).
The problem with restarting applications and subsystems is that you
never know if the loose state information if you just restart them
(e.g. Inkscape going down on upgrade would be pretty annoying). Also,
if e.g. a bug in a shared library gets fixed which is used by many
programs, you would have to re-execute quite a lot of stuff. On
servers, I expect people to handle that and know about this, but for
desktop users, I see some value in offline-updating.
Restarting the whole system is a pretty pragmatic solution for the
problem, you have to restart to use a new kernel as well anyway.
One thing I personally disagree with is how this is implemented
technically at time (we have systemd, which can reliably enter
different targets (runlevels) and ensure services are started and
stopped properly, but we still reboot twice "for safety reasons"), but
Lennart has a different opinion (and admittedly some valid points
about his position).
Relevant things to read:
http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
One thing I want to highlight again is that this would be a pretty
non-invasive change for users used to the existing behaviour, and that
the decision to use it lies by the Debian desktop teams (KDE/GNOME)
and their upstreams, which implement it or not.
What I want to do for Jessie+1 is implement this reliably - it should
better be working properly than being half-usable.
Cheers,
Matthias
--
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
Reply to: