From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] profiles: Add 'hicolor' and 'HighContrast' icon theme hooks. Date: Sun, 10 May 2015 21:57:08 +0200 Message-ID: <87lhgwcijv.fsf@gnu.org> References: <1431147336-4274-1-git-send-email-iyzsong@gmail.com> <877fsixrmg.fsf@gmail.com> <87wq0hg7td.fsf@gnu.org> <87twvlghfk.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48339) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrXLg-0003Uk-K1 for guix-devel@gnu.org; Sun, 10 May 2015 15:57:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YrXLb-00016N-KM for guix-devel@gnu.org; Sun, 10 May 2015 15:57:16 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YrXLb-00016J-Go for guix-devel@gnu.org; Sun, 10 May 2015 15:57:11 -0400 In-Reply-To: <87twvlghfk.fsf@gmail.com> (=?utf-8?B?IuWui+aWh+atpiIncw==?= message of "Sun, 10 May 2015 12:55:27 +0800") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?utf-8?B?5a6L5paH5q2m?= Cc: guix-devel@gnu.org =E5=AE=8B=E6=96=87=E6=AD=A6 skribis: > Ludovic Court=C3=A8s writes: > >> =E5=AE=8B=E6=96=87=E6=AD=A6 skribis: [...] >>>> + (gexp->derivation (string-append (string-downcase name) "-icon-th= eme") >>>> + build >>>> + #:modules '((guix build utils) >>>> + (guix build union)) >>>> + #:local-build? #t))) >>> When to exclude this derivation? >>> >>> 1. the best would be whether icon dir exists or not >>> but is this posibble to implement? and how? >> >> Currently this is not possible. The builder could depend on all the >> manifest entries and scan them for share/icons directory, but at this >> point it=E2=80=99s already too later because the build has to depend on = GTK+. > Does it mean we can't scan them (manifest-inputs) out of the builder, > because they may haven't be realized? Exactly. >>> 2. whether we have a gtk+ package in profile >> >> That=E2=80=99s no usually the case. For instance, I have Evince and GIM= P in my >> profile, but not GTK+. >> >> What could be done is to check whether GTK+ appears and an direct or >> indirect dependency of the packages being installed. >> >> Currently manifest entries can contain either a package object or a >> store path. In the former case, one has to use package->bag and then >> look for GTK+ in the bag=E2=80=99s transitive inputs. In the latter, ca= se, one >> needs to call =E2=80=98references=E2=80=99 to check whether the store it= em, which is >> already built, depends on GTK+. >> >> When none of the manifest=E2=80=99s packages depends on GTK+, then the h= ook can >> just return #f, like ghc-package-cache-file does. >> >> Does that make sense? > OK, I'll try this way. > > And, which GTK+ we should use to do the icon update? > How about choose the one referenced by manifest entries > (either gtk+-2 or gtk+-3) instead of the latest gtk+-3 deployed? That makes sense. I guess we=E2=80=99re in trouble if there are both GTK+2= and GTK+3 packages in use, no? Thanks, Ludo=E2=80=99.