On Mon, 2013-02-18 at 03:05 -0300, Cristian Rodríguez wrote:

On 02/18/2013 02:39 AM, Michael Catanzaro wrote:

...

I notice that in 12.3 "Install Updates & Restart" now frequently appears on the GNOME shell menu as per http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates

I tried this a few months ago but never got it to work in openSUSE; rather my computer just restarted normally. I figured it was being worked on. But in 12.3 RC1 I have the same issue; my computer just restarts without applying any updates. Is this working for anyone else? It works fine for me in Fedora.*

* If by "fine" we are OK with it being confusingly redundant with the existing GNOME update app. I get the impression that this feature is only half-ready in GNOME 3.6, and we'd lose little by disabling it until 13.1.

As a side note, neither zypper nor YaST delete the prepared update list (in /var/lib/PackageKit/) after an update, so the menu item remains even when there's nothing to install. Not sure what component(s) are at fault, but that really ought to happen.

Michael Catanzaro

This unfortunately is not implemented/tested in openSUSE. We need to check it again for 13.1 as it will help to get rid of quite a few annoying problems with "live system updates"..

It is implemented (GNOME only) but I do feel like it's not tested. =)

On 02/18/2013 11:20 AM, Ruediger Meier wrote:

On Monday 18 February 2013, Michael Catanzaro wrote:

...

I notice that in 12.3 "Install Updates & Restart" now frequently appears on the GNOME shell menu as per http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates

Isn't this a step backwards? I always do updates online and reboot only on kernel updates (if I find it's worth to run the new kernel immediately). Never had serious issues.

No. it is an step to sanity :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El lun 18 feb 2013 13:01:15 CLST, Claudio Freire escribió:

Many messages that tell you to reboot should actually just tell you to re-login. There's a big difference there, regarding running services.

Yeah, the package manager does not know if you need to reboot or re-login. that would require having a list of software which is known to require reboot for upgrade.. I'm afraid that for this to work as expected ( that's different from getting it to work) It needs to apply the updates in a all-or-nothing transaction and return sucess or fail. Currently the package manager installs updates one by one using rpm --force.. that's insane.. but it is the way it is :-| -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 18, 2013 at 1:13 PM, Cristian Rodríguez wrote:

Currently the package manager installs updates one by one using rpm --force.. that's insane.. but it is the way it is :-|

That's not insane. That's broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 18, 2013 at 1:29 PM, Cristian Rodríguez wrote:

El 18/02/13 13:24, Claudio Freire escribió:

...

On Mon, Feb 18, 2013 at 1:13 PM, Cristian Rodríguez wrote:

...

Currently the package manager installs updates one by one using rpm --force.. that's insane.. but it is the way it is :-|

That's not insane. That's broken.

Well, in my opinion yes.. but that was the call made by the person that maintain the package manager, there are probably reasons why it is still working that way.

I can't imagine what those reasons could be, and that in fact explains why every time I tried to use that package manager (instead of yast), every time I got some kind of broken system. So whatever reasons they have, they're simply poor reasons, as they result in system breakage. I can't imagine a reason good enough to warrant system breakage. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 18, 2013 at 01:13:17PM -0300, Cristian Rodríguez wrote:

El lun 18 feb 2013 13:01:15 CLST, Claudio Freire escribió:

...

Many messages that tell you to reboot should actually just tell you to re-login. There's a big difference there, regarding running services.

Yeah, the package manager does not know if you need to reboot or re-login. that would require having a list of software which is known to require reboot for upgrade..

Our updates can be tagged wiuth "needs reboot" "needs desktop relogin" and "needs package manager" restart and we usually tag them. Not all desktop restarts or reboot tags are necessary however, so you only see this seldom.

I'm afraid that for this to work as expected ( that's different from getting it to work) It needs to apply the updates in a all-or-nothing transaction and return sucess or fail. Currently the package manager installs updates one by one using rpm --force.. that's insane.. but it is the way it is :-|

Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 18/02/13 19:59, Michael Catanzaro escribió:

That's exactly how systemd does it. =)

Maybe I am misunderstanding something. SUSE's package manager zypp install packages one by one,this is done by executing the rpm binary. there are no transactions involved and there is no warranty of consistency either. Yes.This is madness, but it is the way it works. systemd of course does not have a package manager, so it must call zypper up or dup with the appropiate parameters in order to behave exactly like a human-made upgrade. Does the implementation internally do this or is calling rpm directly ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 18/02/13 20:34, Michael Catanzaro escribió:

On Mon, 2013-02-18 at 20:18 -0300, Cristian Rodríguez wrote:

...

Does the implementation internally do this or is calling rpm directly ? I'm not sure what exactly it's doing but it's all one big transaction. If you read the description on the systemd wiki, Lennart says he takes a btrf snapshot and just rolls back to that if the update fails. (I don't understand how that works though, when we're using ext4.)

afaik ext4 does not have an snapshotting capability therefore I guess you are at the mercy of the result of the upgrade.. ^_^ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 18.02.2013 17:01, schrieb Claudio Freire:

Care to elaborate?

Many messages that tell you to reboot should actually just tell you to re-login. There's a big difference there, regarding running services.

Think of a Firefox update. Firefox consists of many different files in JavaScript, XUL and other languages, describing the UI, different parts of the application, etc. When showing e.g. a new tab with the Addon manager, one of those files is loaded from disk and displayed. Now, if you update Firefox, those files get replaced with a newer version. If one (or many) users have still a Firefox instance running, this results in a mix of old and new Firefox code running (the binary and the main libraries are still the old ones, since they are running, but many components that are loaded on demand, like the addon manager files mentioned before, are now from the new Firefox version. I guess many people have already seen that happening, and that's also the reason why Ubuntu has a custom Firefox add-on that displays an information bar inside Firefox telling you to restart your browser. So the right way to do updates for software like this is to wait until no Firefox instance is running on the machine. The easiest time where this is guaranteed is actually during shutdown or boot. HTH Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Cristian Rodríguez [2013-02-18 18:21]:

El 18/02/13 13:23, Philipp Wagner escribió:

...

So the right way to do updates for software like this is to wait until no Firefox instance is running on the machine. The easiest time where this is guaranteed is actually during shutdown or boot.

Exactly, that will be the conclusion of any sane person that has suffered the perils of "live updates"..

It does not matter if it is similar to $INSERT_YOUR_HATED_OS_HERE , the only things that matter is :

a) It works or not b) makes the issues derived from live updates go away. c) End of list.

A "Live Upgrade" (the one used in the pre-Solaris 11 days) is actually a pretty good solution to this kind of problem, with reduced downtime while applying updates and the ability to go back to the old system. Way better than this idiotic idea copied from Windows/OS X... -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Philipp Wagner [2013-02-18 18:45]:

Am 18.02.2013 18:30, schrieb Guido Berhoerster:

...

* Cristian Rodríguez [2013-02-18 18:21]:

...

El 18/02/13 13:23, Philipp Wagner escribió:

...

So the right way to do updates for software like this is to wait until no Firefox instance is running on the machine. The easiest time where this is guaranteed is actually during shutdown or boot.

Exactly, that will be the conclusion of any sane person that has suffered the perils of "live updates"..

It does not matter if it is similar to $INSERT_YOUR_HATED_OS_HERE , the only things that matter is :

a) It works or not b) makes the issues derived from live updates go away. c) End of list.

A "Live Upgrade" (the one used in the pre-Solaris 11 days) is actually a pretty good solution to this kind of problem, with reduced downtime while applying updates and the ability to go back to the old system. Way better than this idiotic idea copied from Windows/OS X...

How does it work?

By performing the upgrade not on the running system but a clone of it, after finishing you can reboot into the upgraded system or go back to the old one. Live Upgrade used to require two separate filesystems for that but nowadays in the era of ZFS/btrfs cheaper snapshots can be used. This could probably easily be implemented with snapper, zypper and a bit of duct tape... -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 19.02.2013 00:02, Michael Catanzaro wrote:

On Mon, 2013-02-18 at 17:23 +0100, Philipp Wagner wrote:

...

Am 18.02.2013 17:01, schrieb Claudio Freire:

...

Care to elaborate?

Many messages that tell you to reboot should actually just tell you to re-login. There's a big difference there, regarding running services.

Think of a Firefox update. Firefox consists of many different files in JavaScript, XUL and other languages, describing the UI, different parts of the application, etc. When showing e.g. a new tab with the Addon manager, one of those files is loaded from disk and displayed.

Now, if you update Firefox, those files get replaced with a newer version.

If one (or many) users have still a Firefox instance running, this results in a mix of old and new Firefox code running (the binary and the main libraries are still the old ones, since they are running, but many components that are loaded on demand, like the addon manager files mentioned before, are now from the new Firefox version. I guess many people have already seen that happening, and that's also the reason why Ubuntu has a custom Firefox add-on that displays an information bar inside Firefox telling you to restart your browser.

So the right way to do updates for software like this is to wait until no Firefox instance is running on the machine. The easiest time where this is guaranteed is actually during shutdown or boot.

HTH

Philipp Aha, you broke the use case! Upstream specifically wants to exclude "applications" from offline updates, and use offline updates only for "OS components" -- currently defined by whether or not the package installs a .desktop file.

(But gpk-update-viewer doesn't know it shouldn't be updating "system components" and updates everything anyway.)

From what I heard this .desktop-heuristic is only a workaround, until the updates/packages contain this information itself. Is my understanding correct? I'd think the packager is the one person most qualified to judge whether offline updates for the given package would be beneficial or not.

Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 18, 2013 at 05:23:53PM +0100, Philipp Wagner wrote:

Am 18.02.2013 17:01, schrieb Claudio Freire:

...

Care to elaborate?

Many messages that tell you to reboot should actually just tell you to re-login. There's a big difference there, regarding running services.

Think of a Firefox update. Firefox consists of many different files in JavaScript, XUL and other languages, describing the UI, different parts of the application, etc. When showing e.g. a new tab with the Addon manager, one of those files is loaded from disk and displayed.

Now, if you update Firefox, those files get replaced with a newer version.

If one (or many) users have still a Firefox instance running, this results in a mix of old and new Firefox code running (the binary and the main libraries are still the old ones, since they are running, but many components that are loaded on demand, like the addon manager files mentioned before, are now from the new Firefox version. I guess many people have already seen that happening, and that's also the reason why Ubuntu has a custom Firefox add-on that displays an information bar inside Firefox telling you to restart your browser.

So the right way to do updates for software like this is to wait until no Firefox instance is running on the machine. The easiest time where this is guaranteed is actually during shutdown or boot.

I don't think Firefox is a good example for advocating offline updates. Consider a routine update in the middle of a release cycle on a system with open user sessions and running daemons. 1. Current state: I do a "zypper update", then "zypper ps" and it shows me what needs to be restarted. Pretty good chance it is nothing or one or two daemons which can be restarted safely without anyone noticing. Even if it is not the case, often the remaining problems are just running applications dynamically linked against replaced modules - which actually do not need restart. If I'm unlucky, I need users to relogin and only if I'm very unlucky, I need to reboot the system. 2. Offline updates: for many situations which didn't require it before, you need to do a reboot now. Which requires either to wait untill all users log out (with more users, this may take some time) or forcibly shutting down their sessions (I really don't understand why you chose Firefox which doesn't make much difference between SIGTERM and a crash as your example). Summary? There isn't a single situation in which offline updates would be less intrusive or less annoying for the users or for the admin. In any case when I need user to restart a certain application, you need it as well. In any case when I need user to relogin, you need it as well. In any case when I need to reboot the system, you need it as well. On the other hand, there are many situations when I don't need to do anything and you end up with shutting down all sessions (forcibly or waiting for users) and rebooting the system. You are talking about protecting the user from a potential application crash after an update. But you forget to tell us that you are "protecting" them by requiring a full system reboot so that the application has to go down anyway. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 19 February 2013, Philipp Wagner wrote:

Am 19.02.2013 12:36, schrieb Michal Kubecek:

...

You are talking about protecting the user from a potential application crash after an update. But you forget to tell us that you are

It's usually not a crash, Firefox is just malfunctioning. So actually offline updates would prevent the users from having a malfunctioning (partly working) application. If instead the updates are applied on a reboot during regular maintenance intervals (e.g. at 3am when nobody is logged in), all users are better off.

Don't forget that there are a lot systems where users never log off or where other important processes have to run 24/7. These systems are IMO the more important ones. So better fix existing online update issues instead of requiring a reboot which is simply not possible to do in general. Then online updates would also work on systems where offline updates are possible ... BTW firefox is really a bad example to satisfy offline updates because usually it is malfunctioning very often in cause of many other reasons. So no user would wonder about it. Or "help" your users by doing ... $ killall -11 firefox ... still less annoying than asking them for reboot. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 19.02.2013 18:52, schrieb Christian Boltz:

Hello,

Am Dienstag, 19. Februar 2013 schrieb Ruediger Meier:

...

On Tuesday 19 February 2013, Philipp Wagner wrote:

...

Am 19.02.2013 12:36, schrieb Michal Kubecek:

...

You are talking about protecting the user from a potential application crash after an update. But you forget to tell us that

It's usually not a crash, Firefox is just malfunctioning. So

...

Don't forget that there are a lot systems where users never log off or where other important processes have to run 24/7. These systems are IMO the more important ones.

Agreed, rebooting is not the solution (except for kernel updates ;-)

...

BTW firefox is really a bad example to satisfy offline updates because usually it is malfunctioning very often in cause of many other reasons. So no user would wonder about it. Or "help" your users by doing ... $ killall -11 firefox ... still less annoying than asking them for reboot.

*lol*

Some mails up, I read that ubuntu ships a firefox extension that asks the user to restart firefox after an update. Couldn't we just "steal" this extension? ;-)

I've looked into that extension years ago. It relies on some apt/dpkg feature though. ... and looking into the current version ... It's working differently now and we might be able to "fork" that code and add it to our openSUSE extension. It is some hours work though to adapt (extract and integrate) it to our extension. I'm not sure when I'll have time for that. If anyone with some knowledge about JavaScript and Mozilla Addons would like to give it a try I'll happily help as far as I can. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

В Wed, 20 Feb 2013 12:25:20 +0100 Michal Kubecek пишет:

solution to. The user logging into KDE/Gnome and running an update from there is not a problem - he knows to run "zypper ps" (and zypper actually tells him to do so when it is needed) and can decide what to do according to the result.

No, you are wrong here. Typical user does not even know how to start command line, and of course is not aware of "zypper" or how to understand "zypper ps" output. Subscribers to -devel lists are in no way typical users. So for a desktop targeted at typical user offline update is the least evil solution. Let's face it - there are no resources to guarantee error-free online updates under any combination of installed software and its configuration. And desktop users did reboot to install updates for quite some time, so there is nothing new here. The best thing that can be done here is what Solaris did for years with Live Update. Prepare clone of current system, update it and reboot. Of course technical savvy server admins should have a choice. No question. But again - 24x7 is *NOT* something that can be achieved with single system. Period. If you *really* need 24x7 you have to build high available system where applications can be moved over to allow maintenance work on a node. At which point there is no practical argument against offline updates. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Feb 20, 2013 at 12:22 PM, Michal Kubecek wrote:

...

But again - 24x7 is *NOT* something that can be achieved with single system. Period. If you *really* need 24x7 you have to build high available system where applications can be moved over to allow maintenance work on a node. At which point there is no practical argument against offline updates.

No idea why are you bringing this here. I wasn't talking about 24x7 or high availability. Just about desktop users using the feature of having more than one session open and switching between them - which is a standard feature we offer and provide a comfortable user interface for. And with memory prices being what they are, this scenario is likely to get more and more common.

Yeah, in fact, it happens a lot at home, and everything you say is true: I have a hard time finding a way to "politely" reboot (ie: without killing everyone else's session). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 2013-02-20 at 15:14 -0500, Ken Schneider - openSUSE wrote:

On 02/20/2013 01:37 PM, Claudio Freire pecked at the keyboard and wrote:

...

On Wed, Feb 20, 2013 at 12:22 PM, Michal Kubecek wrote:

...

...

But again - 24x7 is *NOT* something that can be achieved with single system. Period. If you *really* need 24x7 you have to build high available system where applications can be moved over to allow maintenance work on a node. At which point there is no practical argument against offline updates.

No idea why are you bringing this here. I wasn't talking about 24x7 or high availability. Just about desktop users using the feature of having more than one session open and switching between them - which is a standard feature we offer and provide a comfortable user interface for. And with memory prices being what they are, this scenario is likely to get more and more common.

Yeah, in fact, it happens a lot at home, and everything you say is true: I have a hard time finding a way to "politely" reboot (ie: without killing everyone else's session).

And why are we trying to make linux into MS windows in regards to a reboot every time a package gets an update? Why not instead teach users how to use 'zypper ps' to check which processes need to be restarted amd how to restart them. I never reboot except for kernel updates as there is no need.

Guys,, really.. this thread is getting out of control and really boring to read! offline-updates is an OPTION! Nobody (I repeat: NOBODY) forces you to use it... if you wish to do so: use zypper.. or if you wish: use rpm. you prefer yast? Go for it! Or better Apper? be my guest! Or shall it be gpk-applications? Then by all means! BUT GET YOUR LIFE TOGETHER and choose your option. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

El 20/02/13 17:14, Ken Schneider - openSUSE escribió:

And why are we trying to make linux into MS windows

That is not a technical argument, stop making silly appeals to emotion. It does not matter if it is similar to DOS or solaris either, the only thing that matter is if it works or not. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/18/2013 07:02 AM, Cristian Rodríguez wrote:

On 02/18/2013 11:20 AM, Ruediger Meier wrote:

...

On Monday 18 February 2013, Michael Catanzaro wrote:

...

I notice that in 12.3 "Install Updates & Restart" now frequently appears on the GNOME shell menu as per http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates

Isn't this a step backwards? I always do updates online and reboot only on kernel updates (if I find it's worth to run the new kernel immediately). Never had serious issues.

No. it is an step to sanity :-)

No, it's a step to windows like operation -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org