From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Ja9V7-0000u8-Ju for garchives@archives.gentoo.org; Fri, 14 Mar 2008 12:59:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E7AF1E05F9; Fri, 14 Mar 2008 12:59:07 +0000 (UTC) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by pigeon.gentoo.org (Postfix) with ESMTP id 886E9E05F9 for ; Fri, 14 Mar 2008 12:59:07 +0000 (UTC) Received: by nf-out-0910.google.com with SMTP id f5so1514037nfh.26 for ; Fri, 14 Mar 2008 05:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; bh=OG1APvY9OiZfVxHh+r4nc09izRRZDLmbWTAsHIdsbRM=; b=guW+FAOD2eAmvZHnjG3GsQE4DQFFkBZX0deaI9C5cShHxSj8zfshPQeXUWHdM+FaAdv6vCUJcN/qXfoXcAonvjlUeJy2kdssipKigM+nmINmqW62Al/O1ijwzPaW64oFzW/qLcJfRnvl1IUgfCbyWCEpptoe1enlU1NNQzdC2k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=bYV0lmZ+bKlabdN6lHMXJJVqqafxjLAq+lwEHvArnwfVyAkGPSNre2y61nFX1TwnTfeOBMwN+twJC4o+cEsSO5DQEM5ZPX3O5bdO2q9B2Ikdk+AS+/x8sr3DO+BVw42ISOviptDJ9oW0jtNG7FAaeK1o93X3RMbAvdudmqJdW68= Received: by 10.78.166.7 with SMTP id o7mr30702662hue.77.1205499535542; Fri, 14 Mar 2008 05:58:55 -0700 (PDT) Received: from ?192.168.1.67? ( [81.158.99.119]) by mx.google.com with ESMTPS id 30sm6923793hub.7.2008.03.14.05.58.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Mar 2008 05:58:54 -0700 (PDT) From: David Leverton To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses Date: Fri, 14 Mar 2008 12:58:43 +0000 User-Agent: KMail/1.9.7 References: <47DA25CF.10205@gentoo.org> <200803141152.29281.levertond@googlemail.com> <47DA6D7F.4080808@gentoo.org> In-Reply-To: <47DA6D7F.4080808@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803141258.43567.levertond@googlemail.com> X-Archives-Salt: 1cfe1a37-a66f-40b1-9410-4e76156ff29c X-Archives-Hash: 50a15b3df85079a8cfbe88c12670282d On Friday 14 March 2008 12:20:15 R=E9mi Cardona wrote: > David Leverton a =E9crit : > > Maybe worth adding a dummy to the current version of the eclass so that= =20 > > ebuilds can be updated now, instead of suddenly all at once as soon as = the=20 > > new eclass is committed? > > Good idea, I'll see what I can do there. Just to be sure you saw my other message, be careful not to overwrite a use= ful=20 pkg_preinst function defined in some other eclass, until the ebuilds are=20 updated to call both. It should be OK to not export it for now, until=20 everything is fixed. > > SCROLLKEEPER_UPDATE_BIN=3D${SCROLLKEEPER_UPDATE_BIN:=3D"${ROOT}usr/bin/= scroll > >keeper-update"} > > > > Those aren't going to work with cross-compilation (which isn't > > well-supported by the current ebuild format, but best to be > > future-proof), since the executables in ${ROOT} won't be able to run on > > the build machine. > > With Gnome 2.22 (app-text/rarian specifically), scrollkeeper-update is > just a script (that's even just a no-op if I'm not mistaken). So all > this scrollkeeper cruft will just become irrelevant as time goes on. OK, but it's still an issue for gconftool-2 (I /think/ it should be OK to c= all=20 the one in /, as long as you can persuade it to operate on the data in=20 ${ROOT}. > >> export GCONF_CONFIG_SOURCE=3D$(${GCONFTOOL_BIN} > >> --get-default-source) > > > > I confess I don't know much about gconf, but that looks as though it'll > > always return a path in /, not ${ROOT}, so it'll install the schemas in > > the / database. > > IIRC, the path returned in --get-default-source should contain $ROOT > because gconf was installed using $ROOT. So it should be safe. Again, maybe my lack of gconf knowledge is showing and I'm misunderstanding= =20 you, but using ${ROOT} to install a package shouldn't affect how it behaves= =20 at runtime (since you can build a binpkg and install it multiple times to=20 different ${ROOT}s). What happens if you enter the chroot and run=20 gconftool-2 --get-default-source there? It should return just /etc,=20 not /chroot/etc. > So far, no one has complained :) Well, it seems like the sort of thing that could easily go unnoticed. Not= =20 many people are going to know or care if they have schemas installed for an= =20 application that they don't have in /, and I would think most applications= =20 would react gracefully if their schema is missing. > Thanks a lot for your review. No problem. -- gentoo-dev@lists.gentoo.org mailing list