On Friday 14 March 2008 12:20:15 Rémi Cardona wrote:
> David Leverton a écrit :
> > Maybe worth adding a dummy to the current version of the eclass so that 
> > ebuilds can be updated now, instead of suddenly all at once as soon as the 
> > 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 useful 
pkg_preinst function defined in some other eclass, until the ebuilds are 
updated to call both.  It should be OK to not export it for now, until 
everything is fixed.

> > SCROLLKEEPER_UPDATE_BIN=${SCROLLKEEPER_UPDATE_BIN:="${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 call 
the one in /, as long as you can persuade it to operate on the data in 
${ROOT}.

> >>         export GCONF_CONFIG_SOURCE=$(${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 
you, but using ${ROOT} to install a package shouldn't affect how it behaves 
at runtime (since you can build a binpkg and install it multiple times to 
different ${ROOT}s).  What happens if you enter the chroot and run 
gconftool-2 --get-default-source there?  It should return just /etc, 
not /chroot/etc.

> So far, no one has complained :)

Well, it seems like the sort of thing that could easily go unnoticed.  Not 
many people are going to know or care if they have schemas installed for an 
application that they don't have in /, and I would think most applications 
would react gracefully if their schema is missing.

> Thanks a lot for your review.

No problem.
--
gentoo-dev@lists.gentoo.org mailing list

Reply via email to