| 1 |
Hi! |
| 2 |
|
| 3 |
> Is there any fundamentally good reason why you don't check for the |
| 4 |
> presence of /tmp/.X?-lock, which XFree itself checks for to determine if |
| 5 |
> an existing X is running ? |
| 6 |
> |
| 7 |
|
| 8 |
Yes... my blatant ignorance of X! :) You are right /tmp/.X?-lock is |
| 9 |
the way to check for X running. As you can tell, I have no qualms about |
| 10 |
baring my ass in public. That said, sheild your eyes. |
| 11 |
|
| 12 |
I recently, updated several gnome-apps to the current versions (I'm |
| 13 |
composing this in evo 0.99, thanks hallski!). While updating, I ran |
| 14 |
into a couple situations where I hosed my gnome-session out from under |
| 15 |
myself. Normally, you can safely emerge a gnome-app while running a |
| 16 |
gnome-session. However, if the app emerge triggers an update of one of |
| 17 |
the underlying libs through a dependency you will promptly shoot |
| 18 |
yourself in the foot. This happened to me when imlib and gdk-pixbuf |
| 19 |
were updated while emerging the new evolution and gnumeric. It would be |
| 20 |
nice if *critical* gnome-libs ebuilds would check to make sure you are |
| 21 |
not running a gnome-session before merging, and ask you to drop down |
| 22 |
into console mode to do the merge. |
| 23 |
|
| 24 |
I assume that a kde or other desktop environments would have similar |
| 25 |
situations. |
| 26 |
|
| 27 |
tod |
| 28 |
|
| 29 |
ps. I tried duplicating the glibc emerge failure that was reported, but |
| 30 |
didn't see. However, the error was reported after a emerge system, but |
| 31 |
I checked for it with ebuild glibc unpack compile install. Although I |
| 32 |
am sure I would have hosed my self if qmerged, the build and install did |
| 33 |
not fail. |
Archives