From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=DATE_IN_PAST_12_24,DMARC_NONE, INVALID_DATE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from ecomm2.fidnet.com ([216.229.64.81]) by cvs.gentoo.org with smtp (Exim 3.30 #1) id 163J7T-0001yy-00 for gentoo-dev@cvs.gentoo.org; Mon, 12 Nov 2001 08:35:31 -0700 Received: (qmail 20053 invoked from network); 12 Nov 2001 14:36:56 -0000 Received: from dialup-mo-113.rolla.fidnet.com (HELO bogus?192?168?3?11.localmosci) (216.229.74.113) by www.fordland.k12.mo.us with SMTP; 12 Nov 2001 14:36:56 -0000 Subject: Re: [gentoo-dev] glibc ebuilds From: "Tod M. Neidt" To: gentoo-dev@cvs.gentoo.org In-Reply-To: <20011111174551.4a1386bf.karltk@prosalg.no> References: <20011103182505.4024c6e3.erichey2@home.com> <1004816735.14975.1.camel@Q.neidt.net> <1004848524.809.13.camel@nosferatu.lan> <1004870072.786.2.camel@Q.neidt.net> <20011111174551.4a1386bf.karltk@prosalg.no> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Message-Id: <1005575857.25833.2.camel@silica> Mime-Version: 1.0 Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Mon Nov 12 08:36:02 2001 X-Original-Date: 12 Nov 2001 08:37:36 -0600 X-Archives-Salt: 611433b2-95c8-4b2e-a92d-48ebb7412ad1 X-Archives-Hash: b6677e1396671402be5d5fc590af2512 Hi! > Is there any fundamentally good reason why you don't check for the > presence of /tmp/.X?-lock, which XFree itself checks for to determine if > an existing X is running ? > Yes... my blatant ignorance of X! :) You are right /tmp/.X?-lock is the way to check for X running. As you can tell, I have no qualms about baring my ass in public. That said, sheild your eyes. I recently, updated several gnome-apps to the current versions (I'm composing this in evo 0.99, thanks hallski!). While updating, I ran into a couple situations where I hosed my gnome-session out from under myself. Normally, you can safely emerge a gnome-app while running a gnome-session. However, if the app emerge triggers an update of one of the underlying libs through a dependency you will promptly shoot yourself in the foot. This happened to me when imlib and gdk-pixbuf were updated while emerging the new evolution and gnumeric. It would be nice if *critical* gnome-libs ebuilds would check to make sure you are not running a gnome-session before merging, and ask you to drop down into console mode to do the merge. I assume that a kde or other desktop environments would have similar situations. tod ps. I tried duplicating the glibc emerge failure that was reported, but didn't see. However, the error was reported after a emerge system, but I checked for it with ebuild glibc unpack compile install. Although I am sure I would have hosed my self if qmerged, the build and install did not fail.