Mailinglist Archive: opensuse-factory (1564 mails)

< Previous Next >
Re: [opensuse-factory] KPackageKit's purpose
  • From: Guido Berhoerster <gber@xxxxxxxxxxxx>
  • Date: Tue, 22 Nov 2011 00:03:24 +0100
  • Message-id: <20111121230324.GC10743@wopr>
* Roger Luedecke <roger.luedecke@xxxxxxxxx> [2011-11-21 22:18]:
On Monday, November 21, 2011 12:44:25 PM Lars Müller wrote:
On Mon, Nov 21, 2011 at 09:26:47AM +0100, Tim Edwards wrote:
On Monday, November 21, 2011 7:19 AM, "Stefan Seyfried"

<stefan.seyfried@xxxxxxxxxxxxxx> wrote:
On 21.11.2011 00:51, Patrick Shanahan wrote:
it is possible to alter /etc/zypp/zypp.conf to set this as
download in advance.

Actually this is default for quite some time IIUC.

I don't have the netbook with me now to check what was set but it
doesn't protect you if you restart the machine in the middle of it
*installing* the updates, which as far as I can tell is what I did

That's not the only issue.

Consider you have a X11 session running and then parts of your desktop
environment get upgraded. I've seen this causing hanging KDE sessions
several times.

Microsoft Windows does it the right way. They download in background
(even slowing the speed down if the link is congested) and with the next
shutdown they apply the updates.

Yes, even this approach has disadvantages. But to me it sounds like the
most safest one.

At least we have to lock the system agains reboots while updates are

The alternative is to apply updates if available before we allow the
login from the display manager.

It would be nice if the admin is able to decide between apply updates on
shutdown, apply them on boot up, or apply them only on request.

Actually, I think we cuold have a more elegant solution than either. Similar
to the new kernel backup thingamajig scheme we just implemented, we could
it check during boot to make sure there wasn't an interruption in the updates
and if so have it roll back those changes. This would mean having to keep
copies of the packages changed; but in the back of my mind I think we could
it in a way that wouldn't require keeping every RPM ever DL'd.

That's basically reinventing Solaris boot environments which
might become possible with btrfs. The basic idea is to snapshot
the current root fs, clone it, mount the clone and apply the
updates within the context of the clone. Then offer both the
updated clone and the original environment in the grub boot menu,
if everything went ok you boot into the updated clone and
eventually promote it, otherwise you boot back into the original
fs and destroy the clone again. To me the only sane way of
applying package updates and an area where Linux is sorely
Guido Berhoerster
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >