OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
So I'm wondering what the equivalent is on KDE, with about that much detail.
Thanks,
Hello Chris,
It's been awhile since I used KDE for last time but IIRC, both Apper (which I tried back on Arch) and Muon (Kubuntu's package manager) supports offline updates. However at that time none of those systems where using systemd... I will ask to my friends and let you know.
-M.
Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
So I'm wondering what the equivalent is on KDE, with about that much detail.
KDE's packagekit client, apper, does not support offline updates, as far as I'm aware.
-- Rex
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
Note that there's a Fedora-KDE list at https://admin.fedoraproject.org/mailman/listinfo/kde
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
You mean Gnome makes you reboot for every update? I must be misunderstanding what you're saying.
poc
On Tue, 2015-03-24 at 12:44 +0100, Michael Schwendt wrote:
On Tue, 24 Mar 2015 11:14:46 +0000, Patrick O'Callaghan wrote:
You mean Gnome makes you reboot for every update? I must be misunderstanding what you're saying.
Why? Would you mind explaining your thoughts?
To quote the OP:
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
I don't use Gnome so my understanding of this is based only on a literal reading. It appears to say that packages are updated with a tool which among other things causes two reboots. Obviously I know that the user might just employ yum as I do myself (on KDE) but the description of the GUI tool is quite specific. Which is why I asked if that's what really happens. Call it a rhetorical question.
poc
On Tue, 24 Mar 2015 12:45:26 +0000, Patrick O'Callaghan wrote:
I don't use Gnome so my understanding of this is based only on a literal reading. It appears to say that packages are updated with a tool which among other things causes two reboots. Obviously I know that the user might just employ yum as I do myself (on KDE) but the description of the GUI tool is quite specific. Which is why I asked if that's what really happens. Call it a rhetorical question.
You sound as if you're surprised that an update tool applies offline updates with the help of rebooting.
It has never been entirely safe to update/upgrade with Yum. Simply because Yum does not take any precautions, such as making sure the user doesn't use a program while upgrading it, or killing and restarting services in a way it doesn't harm the runtime environment. Offline updates remove some of the pitfalls.
On Tue, 24 Mar 2015, Patrick O'Callaghan wrote:
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
Note that there's a Fedora-KDE list at https://admin.fedoraproject.org/mailman/listinfo/kde
Hey! Thanks. I didn't know that.
billo
On Tue, 2015-03-24 at 15:38 +0100, Michael Schwendt wrote:
On Tue, 24 Mar 2015 12:45:26 +0000, Patrick O'Callaghan wrote:
I don't use Gnome so my understanding of this is based only on a literal reading. It appears to say that packages are updated with a tool which among other things causes two reboots. Obviously I know that the user might just employ yum as I do myself (on KDE) but the description of the GUI tool is quite specific. Which is why I asked if that's what really happens. Call it a rhetorical question.
You sound as if you're surprised that an update tool applies offline updates with the help of rebooting.
The way the description was phrased is not specifically limited to offline updates (they are only mentioned in the message Subject), but rather makes it sound as if this was how *all* updating is normally done under Gnome. I still don't know if that's the case or not. Makes it sound like Windows.
It has never been entirely safe to update/upgrade with Yum. Simply because Yum does not take any precautions, such as making sure the user doesn't use a program while upgrading it, or killing and restarting services in a way it doesn't harm the runtime environment. Offline updates remove some of the pitfalls.
Of course. Every time I use yum I check (using needs-restarting) to see what has to be done. However quite frequently I can update packages without restarting anything, so forcing a restart would be overkill. But as I say, I still don't know of that is what is being said.
poc
On Tue, Mar 24, 2015 at 5:14 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
Note that there's a Fedora-KDE list at https://admin.fedoraproject.org/mailman/listinfo/kde
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
You mean Gnome makes you reboot for every update? I must be misunderstanding what you're saying.
OS updates yes. If it's strictly an application update or install, no.
On Tue, 2015-03-24 at 11:40 -0600, Chris Murphy wrote:
On Tue, Mar 24, 2015 at 5:14 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
Note that there's a Fedora-KDE list at https://admin.fedoraproject.org/mailman/listinfo/kde
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
You mean Gnome makes you reboot for every update? I must be misunderstanding what you're saying.
OS updates yes. If it's strictly an application update or install, no.
That's fine. It's just that from your description I had the impression that the only way to apply updates was from this Restart & Install action.
poc
On Tue, Mar 24, 2015 at 5:57 PM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2015-03-24 at 11:40 -0600, Chris Murphy wrote:
On Tue, Mar 24, 2015 at 5:14 AM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Mon, 2015-03-23 at 17:50 -0600, Chris Murphy wrote:
OK I'm going to display some total KDE ignorance here, hopefully a KDE user can answer this.
Note that there's a Fedora-KDE list at https://admin.fedoraproject.org/mailman/listinfo/kde
On GNOME, gnome-software + packagekit + systemd work together to make the user aware of software updates. This includes any installed applications, as well as OS + kernel updates. The user clicks on Restart & Install in gnome-software, or chooses that option in the reboot/poweroff panel. The system reboots, a special systemd offline updates target is triggered, and packagekit installs all the previously downloaded rpms with a progress indicator, then reboots (again).
You mean Gnome makes you reboot for every update? I must be misunderstanding what you're saying.
OS updates yes. If it's strictly an application update or install, no.
That's fine. It's just that from your description I had the impression that the only way to apply updates was from this Restart & Install action.
If you're using the graphical package manager, yes, this is the only way.
On Tue, 2015-03-24 at 18:24 -0600, Chris Murphy wrote:
That's fine. It's just that from your description I had the
impression
that the only way to apply updates was from this Restart & Install action.
If you're using the graphical package manager, yes, this is the only way.
So updating any package, no matter how trivial, means rebooting? Speaking as someone who has never been a Gnome user, thanks for the clarification. KDE certainly does not do this. I don't know if any other DE does.
poc
On 03/24/2015 05:39 PM, Patrick O'Callaghan wrote:
So updating any package, no matter how trivial, means rebooting? Speaking as someone who has never been a Gnome user, thanks for the clarification. KDE certainly does not do this. I don't know if any other DE does.
That's right if, and only if you use Gnome's built in package updater. If you use yum, yumex or dnf, you're not forced to reboot.
On Tue, 2015-03-24 at 17:33 +0000, Patrick O'Callaghan wrote:
quite frequently I can update packages without restarting anything, so forcing a restart would be overkill.
Likewise... Though, these days, I'm running Mate on a current release, rather than Gnome (I'm using Gnome on some out-of-date installs).
Thus far, I can only remember finding Firefox to foul up if you try to keep using it when an update has been installed. Obviously you need to fully quit and restart it to use the new version, but not so obvious is that it doesn't always fully quit when you think it should have.
Though I don't use a great deal of software, it's rare that I'm using much more than a web browser, mail client, IM client, text editor, and a command line terminal. A few other things get started, from time to time, but those are the few that will be running nearly any time I'm logged in.
Over the years, I've been pleasantly surprised at how well most things (just about everything) handled updates being applied while they were running.
Patrick O'Callaghan:
So updating any package, no matter how trivial, means rebooting? Speaking as someone who has never been a Gnome user, thanks for the clarification. KDE certainly does not do this. I don't know if any other DE does.
Joe Zeff:
That's right if, and only if you use Gnome's built in package updater. If you use yum, yumex or dnf, you're not forced to reboot.
Jeez, but that sounds such a crap encumbrance. Even just a log out and log back in again is a severe nuisance. It's beginning to sound a lot like Windows; built for morons, by morons.
On 03/25/2015 12:18 AM, Tim wrote:
On Tue, 2015-03-24 at 17:33 +0000, Patrick O'Callaghan wrote:
quite frequently I can update packages without restarting anything, so forcing a restart would be overkill.
Thus far, I can only remember finding Firefox to foul up if you try to keep using it when an update has been installed. Obviously you need to fully quit and restart it to use the new version, but not so obvious is that it doesn't always fully quit when you think it should have.
I'm pretty sure that Thunderbird suffers from the same affliction, though maybe not as severely.
On Wed, 25 Mar 2015 14:52:11 +1030, Tim wrote:
Patrick O'Callaghan:
So updating any package, no matter how trivial, means rebooting? Speaking as someone who has never been a Gnome user, thanks for the clarification. KDE certainly does not do this. I don't know if any other DE does.
Joe Zeff:
That's right if, and only if you use Gnome's built in package updater. If you use yum, yumex or dnf, you're not forced to reboot.
Jeez, but that sounds such a crap encumbrance. Even just a log out and log back in again is a severe nuisance. It's beginning to sound a lot like Windows; built for morons, by morons.
How do you restart already running processes after an upgrade of system libraries and/or services, for example?
Log out and log back in is not enough.
On 25 March 2015 at 04:22, Tim ignored_mailbox@yahoo.com.au wrote:
Jeez, but that sounds such a crap encumbrance. Even just a log out and log back in again is a severe nuisance. It's beginning to sound a lot like Windows; built for morons, by morons.
Michael is right. Updating online works 99.8% of the time. The 0.1% time it will corrupt random bits of your file-system, and 0.1% of the time it will leave you vulnerable to the security issue you thought you just "fixed". The only way to fix this so that online updates are safe is to redesign the centralised shared package model we use for distributing applications. The workaround is to use offline updates. This moron has spent about 10 years working on the issue.
Richard
On Tue, 2015-03-24 at 17:47 -0700, Joe Zeff wrote:
On 03/24/2015 05:39 PM, Patrick O'Callaghan wrote:
So updating any package, no matter how trivial, means rebooting? Speaking as someone who has never been a Gnome user, thanks for the clarification. KDE certainly does not do this. I don't know if any other DE does.
That's right if, and only if you use Gnome's built in package updater. If you use yum, yumex or dnf, you're not forced to reboot.
Of course, but in that case the DE is immaterial.
poc
On Wed, 2015-03-25 at 12:07 +0100, Michael Schwendt wrote:
On Wed, 25 Mar 2015 14:52:11 +1030, Tim wrote:
Patrick O'Callaghan:
So updating any package, no matter how trivial, means rebooting? Speaking as someone who has never been a Gnome user, thanks for the clarification. KDE certainly does not do this. I don't know if any other DE does.
Joe Zeff:
That's right if, and only if you use Gnome's built in package updater. If you use yum, yumex or dnf, you're not forced to reboot.
Jeez, but that sounds such a crap encumbrance. Even just a log out and log back in again is a severe nuisance. It's beginning to sound a lot like Windows; built for morons, by morons.
How do you restart already running processes after an upgrade of system libraries and/or services, for example?
I type "systemctl restart <whatever>". Isn't that supposed one of the selling points of systemd?
And to repeat (again): many updates are not to running software, so why should the user be forced to reboot? Even for updates to running programs, or the DE itself, rebooting is often not necessary.
poc
On 25 March 2015 at 13:01, Patrick O'Callaghan pocallaghan@gmail.com wrote:
Even for updates to running programs, or the DE itself, rebooting is often not necessary.
If you find a reliable race-free way of working out which packages can safely be updated at runtime, please let me know. Also, any solution that relies on just looking at what binary links a certain shared library will be referred to the D-Bus homepage.
Richard
On 15-03-25 07:36:08, Richard Hughes wrote:
On 25 March 2015 at 04:22, Tim ignored_mailbox@yahoo.com.au wrote:
Jeez, but that sounds such a crap encumbrance. Even just a log out
and
log back in again is a severe nuisance. It's beginning to sound a
lot
like Windows; built for morons, by morons.
Michael is right. Updating online works 99.8% of the time. The 0.1% time it will corrupt random bits of your file-system,
...
Wow! Can you give an example where this happened?
On Wed, 2015-03-25 at 13:34 +0000, Richard Hughes wrote:
On 25 March 2015 at 13:01, Patrick O'Callaghan pocallaghan@gmail.com wrote:
Even for updates to running programs, or the DE itself, rebooting is often not necessary.
If you find a reliable race-free way of working out which packages can safely be updated at runtime, please let me know. Also, any solution that relies on just looking at what binary links a certain shared library will be referred to the D-Bus homepage.
So why does Fedora provide a command called "needs-updating"?
poc
On 03/25/2015 04:27 PM, Patrick O'Callaghan wrote:
On Wed, 2015-03-25 at 13:34 +0000, Richard Hughes wrote:
On 25 March 2015 at 13:01, Patrick O'Callaghan pocallaghan@gmail.com wrote:
Even for updates to running programs, or the DE itself, rebooting is often not necessary.
If you find a reliable race-free way of working out which packages can safely be updated at runtime, please let me know. Also, any solution that relies on just looking at what binary links a certain shared library will be referred to the D-Bus homepage.
So why does Fedora provide a command called "needs-updating"?
needs-restarting?
poc
On 03/25/2015 02:38 PM, Kevin Cummings wrote:
needs-restarting?
Yes. It's part of yum-utils and will give you a list of every program (except the kernel) that needs to be restarted because of an update. It will throw a large number of spurious errors about not being able to examine parts of /proc if run as a regular user, but still give the right answers. Much simpler to run it as root.
Hello Richards,
Quite interesting to actually talk to someone who actually has his hands dirty and can talk about this issue :)
I remember reading a Lennart's post on his blog about a future when packages will be installing in their own spaces and all of this managed by systemd. Now my question (may be an innocent one, I'm full aware of that) is: Why a core technology piece like the kernel can be patched in place (and I hope we see this awesome feature implemented in the neigh time) but on the contrary there is so much trouble when trying to upgrade other 'simpler' (if you allow me) pieces of software? Damn, I believe that even systemd is designed in a way it can be hot-upgraded too without the need of rebooting the system...
Thanks for your time. -Martin
On Wed, Mar 25, 2015 at 8:36 AM, Richard Hughes hughsient@gmail.com wrote:
On 25 March 2015 at 04:22, Tim ignored_mailbox@yahoo.com.au wrote:
Jeez, but that sounds such a crap encumbrance. Even just a log out and log back in again is a severe nuisance. It's beginning to sound a lot like Windows; built for morons, by morons.
Michael is right. Updating online works 99.8% of the time. The 0.1% time it will corrupt random bits of your file-system, and 0.1% of the time it will leave you vulnerable to the security issue you thought you just "fixed". The only way to fix this so that online updates are safe is to redesign the centralised shared package model we use for distributing applications. The workaround is to use offline updates. This moron has spent about 10 years working on the issue.
Richard
users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 03/25/2015 06:35 PM, Joe Zeff wrote:
On 03/25/2015 02:38 PM, Kevin Cummings wrote:
needs-restarting?
Yes. It's part of yum-utils and will give you a list of every program (except the kernel) that needs to be restarted because of an update. starting will throw a large number of spurious errors about not being able to examine parts of /proc if run as a regular user, but still give the right answers. Much simpler to run it as root.
Yes, I know that. *My* response was to another user's question of why Fedora has a needs-updating program (which you removed), which I could not find, but I *did* find a needs-restarting program....
On 03/25/2015 03:52 PM, Kevin Cummings wrote:
Yes, I know that.*My* response was to another user's question of why Fedora has a needs-updating program (which you removed), which I could not find, but I*did* find a needs-restarting program....
Ah. It looked to me as though you were simply expressing surprise that such a program exists.
On 03/25/2015 03:39 PM, Martin Cigorraga wrote:
Hello Richards,
Quite interesting to actually talk to someone who actually has his hands dirty and can talk about this issue :)
I remember reading a Lennart's post on his blog about a future when packages will be installing in their own spaces and all of this managed by systemd.
That exists in two forms: docker and CoreOS. Both really designed for virtualization stuff (like AWS). Indeed, setting up CoreOS on real hardware is a right pain in the arse.
Now my question (may be an innocent one, I'm full aware of that) is: Why a core technology piece like the kernel can be patched in place (and I hope we see this awesome feature implemented in the neigh time) but on the contrary there is so much trouble when trying to upgrade other 'simpler' (if you allow me) pieces of software? Damn, I believe that even systemd is designed in a way it can be hot-upgraded too without the need of rebooting the system...
Thanks for your time.
I can't say exactly what the criteria are for Linux (a lot of my experience goes back to other OSes), but I'll take a whack at it.
In my experience, it's very dangerous to try to patch the _running_ kernel. One could snapshot it into another chunk of RAM, patch that copy, then switch control to it by poking address registers on the CPU. I'd say it's very involved and still prone to problems (and note I said patching, not installing a new kernel).
Updating software that isn't running is trivial. Updating software that _is_ running also is trivial as long as you keep in mind that the running program is the program BEFORE the update. It's already loaded into RAM, pulled in the libraries it wants loaded along with their private data areas (BSS and data segments). You'd need to stop the currently running program and reload the image from disk (re-run) to get the new version.
If you update libraries a running program uses, it won't get the new libraries until it is restarted since it's already got a copy. In fact, I think any program that starts and wants that updated library will get the old version as it's already in memory.
Some programs demand that they be restarted when updated (actually, that's usually part of the package manager's "postinstall" stuff), typically because the patches or whatever fix a really bad bug or security issue. Some maintainers are a bit overly zealous in this area and insist on restarts even for minor fixes.
There are cases where even a library update might mandate a reboot. For example, let's say there's a big security fix in glibc. I can easily see that insisting on a reboot since pretty much EVERYTHING uses glibc.
To ensure everything is using the new library, you really would need a reboot. If you're truly paranoid, a full-tilt hard (power-off, wait, power-on) reboot to make sure RAM is clean of any potential evil code still lurking around.
"Just because I'm paranoid doesn't mean they AREN'T out to get me!" ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Trying to make digital files uncopyable is like trying to make - - water not wet. -- Bruce Schneier - ----------------------------------------------------------------------
On Wed, 2015-03-25 at 16:42 -0700, Rick Stevens wrote:
If you update libraries a running program uses, it won't get the new libraries until it is restarted since it's already got a copy. In fact, I think any program that starts and wants that updated library will get the old version as it's already in memory.
Are you sure of that? I always assumed that shared libraries are just files and once a file is replaced the normal rules apply, i.e. anything that opened it before the replacement gets the old version, anything that opens it afterwards gets the new one. That's how inconsistencies can arise.
poc
On Thu, 26 Mar 2015 01:01:36 +0000 Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Wed, 2015-03-25 at 16:42 -0700, Rick Stevens wrote:
If you update libraries a running program uses, it won't get the new libraries until it is restarted since it's already got a copy. In fact, I think any program that starts and wants that updated library will get the old version as it's already in memory.
Are you sure of that? I always assumed that shared libraries are just files and once a file is replaced the normal rules apply, i.e. anything that opened it before the replacement gets the old version, anything that opens it afterwards gets the new one. That's how inconsistencies can arise.
I'd second that question. I can easily imagine a running program which loads a library on *demand*, not on its start-up. So a program may start regularly, work for a while, and then try to load some library --- only to find out that the library was updated to an incompatible version in the meantime.
Yum will of course make sure that there is a new version of the program itself which is compatible with the new library, but that is not necessarily the version of the program currently running in memory.
At least, that's how I tend to explain firefox-updating glitches to myself. :-)
Best, :-) Marko
Tim:
Jeez, but that sounds such a crap encumbrance. Even just a log out and log back in again is a severe nuisance. It's beginning to sound a lot like Windows; built for morons, by morons.
Michael Schwendt:
How do you restart already running processes after an upgrade of system libraries and/or services, for example?
Log out and log back in is not enough.
Some of us abandoned crap OSs, like Windows, because we were sick of its reboot disease. Going down that route is seriously annoying. It means you can't do an update without having to set aside time to waste as you go through at least one reboot. And, with Windows, their "reboot all the time" attitude can mean several reboots, as it just doesn't seem to cope with doing everything in one step. Oh look, something changed, better reboot...
Are we, now, going to have that same problem as some things can't handle a state change, that are going to get upset while you're trying to reboot? I've certainly seen Windows get stuck in a prolonged reboot loop. Hell, I've even watched an entire movie while waiting for Windows to finish an update cycle.
Any package that needs a restart (whether that be an update of the thing itself, or an update of a library for a package that will require the thing to be restarted) can have a flag in its RPM that lets the system know. We already have that feature, don't we? Put the onus on the package maintainers to determine if a restart is needed, and pour scorn on those who stupidly just enable it when it's not needed.
The update routine could retrigger the restart at the appropriate time. Far better to have the update routines restart a few processes while the computer carries on, than require me to be doing nothing on the PC while its updating, and then waste more time with reboots. And far better, for us, to not have restarts and reboots inflicted upon us if we do not really need them.
On 26 March 2015 at 01:25, Marko Vojinovic vvmarko@gmail.com wrote:
On Thu, 26 Mar 2015 01:01:36 +0000 Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Wed, 2015-03-25 at 16:42 -0700, Rick Stevens wrote:
If you update libraries a running program uses, it won't get the new libraries until it is restarted since it's already got a copy. In fact, I think any program that starts and wants that updated library will get the old version as it's already in memory.
Are you sure of that? I always assumed that shared libraries are just files and once a file is replaced the normal rules apply, i.e. anything that opened it before the replacement gets the old version, anything that opens it afterwards gets the new one. That's how inconsistencies can arise.
I'd second that question. I can easily imagine a running program which loads a library on *demand*, not on its start-up. So a program may start regularly, work for a while, and then try to load some library --- only to find out that the library was updated to an incompatible version in the meantime.
Yum will of course make sure that there is a new version of the program itself which is compatible with the new library, but that is not necessarily the version of the program currently running in memory.
At least, that's how I tend to explain firefox-updating glitches to myself. :-)
It may be that firefox is one of a few applications that work this way. My understanding, which could be wrong, is that linked dynamic libraries (those that get found by the compiler and linked while building, because they are used by a program in a normal 'call this function' way and without which available it will not build) get found and loaded at start time. There are system calls to allow you to read in functions from libraries at run time, these are less commonly used as it's harder work and only needed for things like providing module support. Applications doing that are still likely to search for and load their modules at start-up, but could still try to load more functions later. Not sure what firefox is having to do to keep tabs separate from each other, may be loading separate instances of libraries for that.
On Thu, 2015-03-26 at 14:29 +1030, Tim wrote:
Any package that needs a restart (whether that be an update of the thing itself, or an update of a library for a package that will require the thing to be restarted) can have a flag in its RPM that lets the system know. We already have that feature, don't we? Put the onus on the package maintainers to determine if a restart is needed, and pour scorn on those who stupidly just enable it when it's not needed.
needs-restarting already detects automatically when a running process is using an obsoleted component, except for the kernel, and since most people keep at least 2 or 3 kernels around, you can usually (always?) put off rebooting a new kernel until you're ready.
What would be genuinely useful would be a tool to tell you how to get to a clean system with minimum fuss, e.g. one of:
* restart the following user processes: a b c ... * log out and in again * reboot the system
You could even wrap it in a GUI to keep the CLI-challenged happy.
poc
On Thu, 2015-03-26 at 12:58 +0000, Patrick O'Callaghan wrote:
What would be genuinely useful would be a tool to tell you how to get to a clean system with minimum fuss, e.g. one of:
- restart the following user processes: a b c ...
- log out and in again
- reboot the system
Rather than tell you how to do it, it ought to ask you whether its allowed to do what it needs to. i.e. Tell you that it needs to restart the following listed services, and you'd allow or defer it.
And if there was a mixture, such as restarting Apache, re-logging to apply things to pertaining to your desktop, and rebooting for a new kernel. You'd individually authorise each step, skip any you want to defer, or just go for a reboot to avoid typing in "y" a dozen times.
It's the computer, not you, let it do the damn work.
On Fri, 2015-03-27 at 00:54 +1030, Tim wrote:
On Thu, 2015-03-26 at 12:58 +0000, Patrick O'Callaghan wrote:
What would be genuinely useful would be a tool to tell you how to get to a clean system with minimum fuss, e.g. one of:
- restart the following user processes: a b c ...
- log out and in again
- reboot the system
Rather than tell you how to do it, it ought to ask you whether its allowed to do what it needs to. i.e. Tell you that it needs to restart the following listed services, and you'd allow or defer it.
I meant the list to be read as a menu to be clicked on.
And if there was a mixture, such as restarting Apache, re-logging to apply things to pertaining to your desktop, and rebooting for a new kernel. You'd individually authorise each step, skip any you want to defer, or just go for a reboot to avoid typing in "y" a dozen times.
More complicated but sure.
It's the computer, not you, let it do the damn work.
Exactly.
poc
-
Chris Murphy -
Ian Malone -
Joe Zeff -
Kevin Cummings -
Marko Vojinovic -
Martin Cigorraga -
Michael Schwendt -
Patrick O'Callaghan -
Rex Dieter -
Richard Hughes -
Rick Stevens -
Tim -
Tony Nelson -
William Oliver