A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
On 07/20/2011 10:38 PM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
I have same problem.
Any update that touches kde seems to crash plasma-desktop - and logout/login is required ..
fully updated F15 here ... did you file a bug?
On 21 July 2011 12:52, Genes MailLists lists@sapience.com wrote:
On 07/20/2011 10:38 PM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
I have same problem.
Any update that touches kde seems to crash plasma-desktop - and logout/login is required ..
fully updated F15 here ... did you file a bug?
Not yet. Wanted to see what others thought.
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Jim Dean jdean55@gmail.com wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
It was suggested that a bug should be raised for it. mailing list
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
I find it difficult for anyone to expect updates to complex interdependent running binaries to continue to function correctly while and after updates to them are applied. I always turn off automatic desktop updaters and update notifiers, usually exit X before applying updates, and when not, restart immediately after application completes, if not reboot the system.
On 07/21/2011 08:29 AM, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
I find it difficult for anyone to expect updates to complex interdependent running binaries to continue to function correctly while and after updates to them are applied. I always turn off automatic desktop updaters and update notifiers, usually exit X before applying updates, and when not, restart immediately after application completes, if not reboot the system.
nod, one thing I'm looking forward to presumably coming in packagekit soonish, is the ability to apply updates on shutdown.
-- rex
On 07/21/2011 09:32 AM, Rex Dieter wrote:
I find it difficult for anyone to expect updates to complex interdependent running binaries to continue to function correctly while and after updates to them are applied. I always turn off automatic desktop updaters and update notifiers, usually exit X before applying updates, and when not, restart immediately after application completes, if not reboot the system.
nod, one thing I'm looking forward to presumably coming in packagekit soonish, is the ability to apply updates on shutdown.
sort of ... a running program -typically will continue to function just fine even if it is unlinked and a new one put in place - its possible paging from the file may be an issue but far more likely is that a subordinate program gets started which is not new and now in some way conflicts.
none of this explains why plasma-desktop crashes and burns. This seems far more likely to be a bug to me - it should function fine during and after an update - if logout is necessary, or a reboot (on very odd occasions) fine ... don't crash the desktop before that happens.
Also
On 07/21/2011 10:25 AM, Genes MailLists wrote:
sort of ... a running program -typically will continue to function just fine even if it is unlinked and a new one put in place - its possible paging from the file may be an issue but far more likely is that a subordinate program gets started which is not new and now in some
^^^^^^^^^^^^^^^^^ should be which is new and now conflicts
Genes MailLists wrote:
sort of ... a running program -typically will continue to function just fine even if it is unlinked and a new one put in place - its possible paging from the file may be an issue but far more likely is that a subordinate program gets started which is not new and now in some way conflicts.
none of this explains why plasma-desktop crashes and burns. This seems far more likely to be a bug to me - it should function fine during and after an update - if logout is necessary, or a reboot (on very odd occasions) fine ... don't crash the desktop before that happens.
Plasma loads plugins at runtime. If the version of the plugin on disk doesn't match the version of the main program in memory, it will fail to load. This also affects some other KDE programs.
Kevin Kofler
Am 21.07.2011 15:32, schrieb Rex Dieter:
On 07/21/2011 08:29 AM, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
I find it difficult for anyone to expect updates to complex interdependent running binaries to continue to function correctly while and after updates to them are applied. I always turn off automatic desktop updaters and update notifiers, usually exit X before applying updates, and when not, restart immediately after application completes, if not reboot the system.
nod, one thing I'm looking forward to presumably coming in packagekit soonish, is the ability to apply updates on shutdown.
It would be great as well if shutdown is not possible during update. I once shut down my system during update and afterwards there were some problems. Windows tells the user not to turn of the system until update is finished.
Martin
-- rex _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Martin (KDE) wrote:
It would be great as well if shutdown is not possible during update. I once shut down my system during update and afterwards there were some problems. Windows tells the user not to turn of the system until update is finished.
PackageKit is actually supposed to block shutdowns…
Kevin Kofler
On Thu, 2011-07-21 at 09:29 -0400, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
I find it difficult for anyone to expect updates to complex interdependent running binaries to continue to function correctly while and after updates to them are applied. I always turn off automatic desktop updaters and update notifiers, usually exit X before applying updates, and when not, restart immediately after application completes, if not reboot the system.
See the recent thread on "needs-updating" on the Users list.
Updating the on-disc binary of a running process has no effect on said process, it simply creates a new file. New execs of the program will execute from that file rather than the old one, but the old one will persist until the last running instance of it dies. Of course problems can in theory arise if a set of interacting processes are partially updated, depending on exactly when each of them executes, but in practice I've rarely seen any problems with this (mainly I think because apps don't tend to change radically from one version to the next, especially in their external interfaces).
The main reason for restarting a session is to get the new version of long-running components, which would include plasma and the like.
poc
On Thursday 21 July 2011 16:51:17 Patrick O'Callaghan wrote:
Updating the on-disc binary of a running process has no effect on said process, it simply creates a new file. New execs of the program will execute from that file rather than the old one, but the old one will persist until the last running instance of it dies. Of course problems can in theory arise if a set of interacting processes are partially updated, depending on exactly when each of them executes, but in practice I've rarely seen any problems with this (mainly I think because apps don't tend to change radically from one version to the next, especially in their external interfaces).
What about this scenario: an app A occasionally loads a library B in order to use some code from there. Suppose that while A is running (and did not load B yet because user interaction didn't require it so far) there is an update to both A and B (which goes to disk). After this happens, the system is in a potentially inconsistent state --- if a user interacts with A so that A asks to load B, the *updated* library B will be loaded, which can break A badly, depending on the difference between old and new B. If A is restarted, everything will be ok, of course, but until then the *old* A is running from memory, and loading the new B is a gamble, in general.
For system daemons and services (and even for init AFAIK) this is being solved by the automatic restart of the service after the update (I guess this is in the rpm's "post"-part of the install), so the system is kept in consistent state.
For DE and its apps, the story is different, since rpm cannot "restart" the whole DE while the user is logged in. So there is no way for a system to keep the DE and its apps in a consistent state after the update, if the user is still working in it.
This happens fairly often, in the case of firefox I would say regularly --- every time I see firefox being updated in the yum listing, I save all tabs before the update begins, close it and reopen it after the update. Every time I miss to do that, I get burned by the running version of firefox starting to malfunction in all sorts of weird ways.
Aside from firefox crashing/misbehaving regularly after an update, I remember that this happened once with ktorrent as well. It was updated while running (in the background), and it crashed when I opened up its window again. A simple restart fixed it.
All that said, on F14 plasma never crashed on me, updates or otherwise. Of course, if I see kde* packages being updated in the yum listing, I either postpone the update for later, or save my data, logout and login after the update. I am not saying that this is a big issue, it rarely happens, but if you don't want nasty surprises, it's better to be on the safe side.
HTH, :-) Marko
On Fri, 2011-07-22 at 04:39 +0100, Marko Vojinovic wrote:
On Thursday 21 July 2011 16:51:17 Patrick O'Callaghan wrote:
Updating the on-disc binary of a running process has no effect on said process, it simply creates a new file. New execs of the program will execute from that file rather than the old one, but the old one will persist until the last running instance of it dies. Of course problems can in theory arise if a set of interacting processes are partially updated, depending on exactly when each of them executes, but in practice I've rarely seen any problems with this (mainly I think because apps don't tend to change radically from one version to the next, especially in their external interfaces).
What about this scenario: an app A occasionally loads a library B in order to use some code from there. Suppose that while A is running (and did not load B yet because user interaction didn't require it so far) there is an update to both A and B (which goes to disk). After this happens, the system is in a potentially inconsistent state --- if a user interacts with A so that A asks to load B, the *updated* library B will be loaded, which can break A badly, depending on the difference between old and new B. If A is restarted, everything will be ok, of course, but until then the *old* A is running from memory, and loading the new B is a gamble, in general.
That could happen but it would depend on how the library is loaded. I'm not sufficiently au fait with the details of Linux dynamic library management to have a well-founded opinion, but AFAIK the loader normally checks that all libraries exist before allowing the process to execute. Whether that means the library files are open or not is another matter. To put it another way: will the process die if the .so file is deleted while it's still running? If it does, then the problem you mention could arise, and if not, not. Testing this is left as an exercise for the reader :-)
poc
Patrick O'Callaghan wrote:
That could happen but it would depend on how the library is loaded. I'm not sufficiently au fait with the details of Linux dynamic library management to have a well-founded opinion, but AFAIK the loader normally checks that all libraries exist before allowing the process to execute.
That's only true if the library is linked directly, not if dlopen is used. Plugins are loaded through dlopen.
Kevin Kofler
On Tue, 2011-07-26 at 12:44 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
That could happen but it would depend on how the library is loaded. I'm not sufficiently au fait with the details of Linux dynamic library management to have a well-founded opinion, but AFAIK the loader normally checks that all libraries exist before allowing the process to execute.
That's only true if the library is linked directly, not if dlopen is used. Plugins are loaded through dlopen.
Good point.
poc
On 07/26/2011 12:48 PM, Patrick O'Callaghan wrote:
On Tue, 2011-07-26 at 12:44 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
That could happen but it would depend on how the library is loaded. I'm not sufficiently au fait with the details of Linux dynamic library management to have a well-founded opinion, but AFAIK the loader normally checks that all libraries exist before allowing the process to execute.
That's only true if the library is linked directly, not if dlopen is used. Plugins are loaded through dlopen.
Good point.
poc
Only up to a point - this is a possible explanation but not a valid reason.
Usually, calls to dlopen use some kind of version indicator to ensure compatibility before blindly executing code which may not be compatible - this allows graceful 'please logout to pick up new libraries' notification to the user (or whatever).
dlopen() needs some protection - if its not doing this, I'd claim its still a bug (badly written).
The GUI needs to be graceful and not just 'hang' coz an update took place.
One could even keep both (or more) sets of libraries in place until the next reboot/KDE restart or whatever - so that things could just keep working.
Crashing is never excusable ... and certainly using dlopen() poorly is not a good excuse - its merely an explanation of the bug.
On 07/21/2011 09:29 PM, Felix Miata wrote:
On 2011/07/21 15:16 (GMT+0800) Ed Greshko composed:
Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
FWIW, I have not seen this problem. Last update, I waited 2 days before a logout/login.
I find it difficult for anyone to expect updates to complex interdependent running binaries to continue to function correctly while and after updates to them are applied. I always turn off automatic desktop updaters and update notifiers, usually exit X before applying updates, and when not, restart immediately after application completes, if not reboot the system.
I agree with you, in the sense that it is probably unrealistic to expect that a session will continue to run for an infinite time after components have been updated. I have not, so far, had a session deteriorate due to updates being performed but lacking a logout/login session.
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things did go a bit odd after the kde 4.5.x to 4.6 update until we logged out and in again.
Roderick
On 21/07/11 09:21, Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things did go a bit odd after the kde 4.5.x to 4.6 update until we logged out and in again.
Roderick
A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to needs-restarting, which is part of the yum-utils package.
[John@localhost ~]$ needs-restarting --help Usage: needs-restarting: Report a list of process ids of programs that started running before they or some component they use were updated.
Options: -h, --help show this help message and exit -u, --useronly show processes for my userid only [John@localhost ~]$
Null output suggests that all should be ok.
I haven't used this because I thought it might be yum-specific, and I normally use smart, but this --help info makes it look depsolver agnostic.
John P
On 07/21/2011 06:17 AM, John Pilkington wrote:
I don't use f14 so for me its f15 only. Also, if I have a new kernel - i should restart - but this has nothing to do with plasma-desktop freezing up nor should it be a problem if I don't reboot for that matter.
existing windows (terminal for example) work - but the desktops are all collapsed into 1 - and nothing on any panel responds to anything.
On Thu, 2011-07-21 at 11:17 +0100, John Pilkington wrote:
On 21/07/11 09:21, Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things did go a bit odd after the kde 4.5.x to 4.6 update until we logged out and in again.
Roderick
A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to needs-restarting, which is part of the yum-utils package.
[John@localhost ~]$ needs-restarting --help Usage: needs-restarting: Report a list of process ids of programs that started running before they or some component they use were updated.
Options: -h, --help show this help message and exit -u, --useronly show processes for my userid only [John@localhost ~]$
Null output suggests that all should be ok.
I haven't used this because I thought it might be yum-specific, and I normally use smart, but this --help info makes it look depsolver agnostic.
It has nothing to do with yum, or indeed with depsolvers of any sort. It just looks at the actual running binary and checks the file(s) it came from. Which is pretty cool IMHO. The code is a page or two of Python and is very educational to read.
poc
On 21/07/11 16:53, Patrick O'Callaghan wrote:
On Thu, 2011-07-21 at 11:17 +0100, John Pilkington wrote:
On 21/07/11 09:21, Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things did go a bit odd after the kde 4.5.x to 4.6 update until we logged out and in again.
Roderick
A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to needs-restarting, which is part of the yum-utils package.
[John@localhost ~]$ needs-restarting --help Usage: needs-restarting: Report a list of process ids of programs that started running before they or some component they use were updated.
Options: -h, --help show this help message and exit -u, --useronly show processes for my userid only [John@localhost ~]$
Null output suggests that all should be ok.
I haven't used this because I thought it might be yum-specific, and I normally use smart, but this --help info makes it look depsolver agnostic.
It has nothing to do with yum, or indeed with depsolvers of any sort. It just looks at the actual running binary and checks the file(s) it came from. Which is pretty cool IMHO. The code is a page or two of Python and is very educational to read.
poc
I looked at it and had my doubts; the script includes what looked to me like a reference to the yum cache but I didn't work out how essential this is to its operation. And I suppose it's best run as root?
John P
On Thu, 2011-07-21 at 18:29 +0100, John Pilkington wrote:
On 21/07/11 16:53, Patrick O'Callaghan wrote:
On Thu, 2011-07-21 at 11:17 +0100, John Pilkington wrote:
On 21/07/11 09:21, Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things did go a bit odd after the kde 4.5.x to 4.6 update until we logged out and in again.
Roderick
A post on Fedora-users (poc, 28/06/11 17:22) drew my attention to needs-restarting, which is part of the yum-utils package.
[John@localhost ~]$ needs-restarting --help Usage: needs-restarting: Report a list of process ids of programs that started running before they or some component they use were updated.
Options: -h, --help show this help message and exit -u, --useronly show processes for my userid only [John@localhost ~]$
Null output suggests that all should be ok.
I haven't used this because I thought it might be yum-specific, and I normally use smart, but this --help info makes it look depsolver agnostic.
It has nothing to do with yum, or indeed with depsolvers of any sort. It just looks at the actual running binary and checks the file(s) it came from. Which is pretty cool IMHO. The code is a page or two of Python and is very educational to read.
poc
I looked at it and had my doubts; the script includes what looked to me like a reference to the yum cache but I didn't work out how essential this is to its operation. And I suppose it's best run as root?
I spoke too soon. It looks at the RPM database to discover if any of a process' open files belong to some package that was installed after the process started. This would of course include the binary executable of the process itself and those of any libraries it has loaded.
poc
On Thursday, July 21, 2011 09:21:38 AM Roderick Johnstone wrote:
On 21/07/11 03:38, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
This doesn't seem to be a problem for us on F14 usually, although things did go a bit odd after the kde 4.5.x to 4.6 update until we logged out and in again.
Fedora 14 here. I always log out after updates affect KDE packages. Mostly it works without a problem, but I have seen a couple of cases where a hard reboot was necessary. I don't consider it to be enough to make an issue of it.
Anne
On 07/20/2011 09:38 PM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people?
Even minor kde-4.x.y updates (where y increments), a session restart is recommended. for major (x increments) updates, we set the flag to request a reboot. These session or restart recommendations are exposed via PackageKit (and kpackagekit) when applying updates.
-- rex
Rex Dieter wrote:
Even minor kde-4.x.y updates (where y increments), a session restart is recommended. for major (x increments) updates, we set the flag to request a reboot.
Is this still necessary? KPackageKit is supposed to detect running apps and request a session restart, for me it normally does. A full reboot is not actually required, and we've had trouble with the "request reboot" flag in the past (the flag would infect all further updates, even just of one of the packages). I don't think we should be setting "request reboot" for any KDE update anymore.
Kevin Kofler
On 07/21/2011 03:38 AM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
What is so surprising about that? :-)
You are changing the whole system behind the carpet and you expect it to just work?
The only solution for it to work would be to have everything loaded on memory.
On Thu, 2011-07-21 at 15:38 +0100, José Matos wrote:
On 07/21/2011 03:38 AM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
What is so surprising about that? :-)
You are changing the whole system behind the carpet and you expect it to just work?
Mostly yes, I do. This isn't Windows.
poc
On Thursday, July 21, 2011 04:54:19 PM Patrick O'Callaghan wrote:
On Thu, 2011-07-21 at 15:38 +0100, José Matos wrote:
On 07/21/2011 03:38 AM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
What is so surprising about that? :-)
You are changing the whole system behind the carpet and you expect it to just work?
Mostly yes, I do. This isn't Windows.
I'm thankful that it manages things well enough for me to always finish whatever I was doing. However, my thinking is that if I start anything new that calls one of the new packages I am asking for a conflict with the old packages that I'm still running. It simply isn't worth the risk. And after all, a logout is nowhere near the same as a Windows reboot.
Anne
On Thu, 2011-07-21 at 18:51 +0100, Anne Wilson wrote:
On Thursday, July 21, 2011 04:54:19 PM Patrick O'Callaghan wrote:
On Thu, 2011-07-21 at 15:38 +0100, José Matos wrote:
On 07/21/2011 03:38 AM, Jim Dean wrote:
A recent discussion on Fedora forums raised the need to logout and back after a KDE version update. I've noticed that the system becomes unstable, last time I got a plasma crash, and others reported similar things. Is this common or just a few people? It was suggested that a bug should be raised for it.
What is so surprising about that? :-)
You are changing the whole system behind the carpet and you expect it to just work?
Mostly yes, I do. This isn't Windows.
I'm thankful that it manages things well enough for me to always finish whatever I was doing. However, my thinking is that if I start anything new that calls one of the new packages I am asking for a conflict with the old packages that I'm still running. It simply isn't worth the risk. And after all, a logout is nowhere near the same as a Windows reboot.
I do the same, not so much because I think anything will go wrong if I don't but for general motives of paranoia. When I say this isn't Windows, I mean that Linux gives you great leeway in deciding when to do it while Windows frequently demands a reboot even for trivial changes. The underlying reason has much to do with the very elegant Unix file model, which IMHO Mr. Gates totally failed to understand when he started selling MS-DOS, but that's another story.
poc
On 07/21/2011 04:54 PM, Patrick O'Callaghan wrote:
Mostly yes, I do. This isn't Windows.
poc
Please, let us keep this discussion on a polite level. ;-)
I still remember the .la files that were libraries loaded on demand by kde. If that is the case it is asking for trouble to have the infrastructure with one version and the (new) loaded libraries with another since they do not match any more.
-
Anne Wilson -
Ed Greshko -
Felix Miata -
Genes MailLists -
Jim Dean -
John Pilkington -
José Abílio Matos -
Kevin Kofler -
Marko Vojinovic -
Martin (KDE) -
Patrick O'Callaghan -
Rex Dieter -
Roderick Johnstone