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=0.2 required=5.0 tests=DATE_IN_PAST_12_24, DMARC_MISSING,INVALID_DATE,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=no autolearn_force=no version=4.0.0 Received: from front2.mail.megapathdsl.net ([66.80.60.30]) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15rPBx-0008Rs-00 for gentoo-dev@cvs.gentoo.org; Wed, 10 Oct 2001 13:38:58 -0600 Received: from [64.32.225.42] (HELO there) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.4.8a) with SMTP id 8687249 for gentoo-dev@cvs.gentoo.org; Wed, 10 Oct 2001 12:29:55 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Gold is Heavy To: gentoo-dev@cvs.gentoo.org X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: Subject: [gentoo-dev] GNOME and KDE, can they play nice? was: merging gaim... 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: Wed Oct 10 13:39:02 2001 X-Original-Date: Wed, 10 Oct 2001 15:38:44 -0400 X-Archives-Salt: a536ecfa-0fca-4f39-900e-6cf2624eb3ef X-Archives-Hash: d14453f8e0435c68eb7003ee9384af32 Hi Martin and other Gentoo Hackers, Martin said: "Try the following: Make sure gnome is in use flags, then remerge gdk-pixbuf. Then make sure gnome-base/gnome-core and gnome-base/gnome-libs are merged, and remerge Pan." Ok I followed these steps, and I noticed that gnome-base/gnome-core and gnome-base/gnome-libs are indeed merged on my box. (I looked in /var/db/pkg to check this.) And it didn't help, but you probably knew that by now :) Then, Martin said: "You have gnome in your USE-variables (in /etc/make.conf), that's why gnome-support is built. If you don't want GNOME-support, remove gnome from your use-variables." Ok, I am beginning to understand the USE flags a little better now. However this brings up a serious question. What about people who want to use BOTH GNOME and KDE?? Personally, I will most likely take out 'gnome' from my USE flags and try again, but... There might be very valid and good reasons why someone might want to run both KDE and GNOME on the same box. Possible scenarios: 1. More than one person uses the box at home, and they have different preferences. 2. The box is in a computer lab, and many people use it there. Again, they might have different preferences. 3. Someone likes to switch between Gnome and KDE on a whim, just for the fun of it. One possible solution that I can see: When building apps, check both KDE AND GNOME flags. If both of them are defined, make the app usable in both environments. For gaim, that would mean sacrificing the applet functionality, and maybe gnome bits. So, the ebuilds would be sensitive to both variables and there would be 4 possible actions that could be taken: a) neither KDE nor GNOME defined, b) KDE only, c) GNOME only and d) usable under both KDE and GNOME. More generally, if there are more that one desktop environment flags in USE flags, then emerge/ebuild should avoid building an application that is hardwired to only one desktop environment. So, this could be generalized away from just KDE/Gnome distinction. This could be further generalized away from even desktop environments. How about creating a new variable called ALTERNATIVE or something like that? Then we could say: ALTERNATIVE="desktop_environment kde gnome" ALTERNATIVE="database postgre mysql" ...and so on, and what it would mean is this: if there are ALTERNATIVE desktop_environment's in place, be sensitive to that fact by NOT building apps that do not work with ALL of the alternatives. If there are alternative database's in use, then do NOT build apps that can only use one database and not the other. The primary use for this would probably be for DEs and maybe databases, but if any other alternatives should crop up, it would be very easy to handle them all with a flexible and general system. Just an idea :). --Leo