begin quote
On Mon, 13 Jan 2003 21:32:43 +0100
Christian Lohmaier <cloph cup uni-muenchen de> wrote:
>
> So in this case it's better to use %{_bindir}/gconftool-2
yep, thats a good idea.
>
> > Can we also make sure that our .spec's follow the FHS?
>
> Yes. At least I think that my packages follow the FHS :-)
> But I don't think that it's the spec that guarantees cpmliance with
> the FHS, it's the packages's rpmmacros that do the work.
> Eg in the spec just %configure is specified, the values for
> prefix,etc. come from the packager's settings...
aye, this is good, then we allow our users to break the FHS when they
want to as well, simply by reconfiguring their local rpm-set paths ;)
<SNIP scrollkeeper>
> > > > General packaging guidelines? are there any? How do we as the
> > > > Gnome project want the distributors to treat Gnome packages?
> > This is something we need to put together, preferrably :)
> I'd love to see some official guidelines for this on www.gnome.org
So we havea a consensus that we want official guidelines.. now what? ; )
<< "on the issue of schemas" >>
> We can make it work by introducing some trickery. It's possible to
> create a 'all_schemas.list' during %install (using find & basename or
> something similar) and install this one along with the regular files.
> During %post one could read that file and delete it after installing
> the schemas mentioned therein.
See my helperscript in last post, that works nice for me :)
> > > > portability, maintainability and generic items are a great
> > > > thing.. Too bad that theres no way to include a special package
> > > > of "gnome macros" for .spec.. .or none that I know of, someone
> > > > here might know better.
> > >
> > > How would such a gnome-macro look like?
> > %gconf-install
> > <find .spec, find gconftool-2, install, check all is ok and go>
> ^^^^^^^^^^
> I assume that this should read .schemas
> This is hard, at least I don't know a descent way to pick the newly
> installed schemas only. And 'find gconftool-2' is not really the way
> I'd like things to work..
Aye, see the script at the end of last post for details..
>
>
> > What I meant to express was a regret of inheritance in the .spec
> > system, we cannot provide a general include in say "gconf" that
> > would provide the .spec helper scripts that all packages that depend
> > on gconf can use... or can we?
>
> Interesting thought. I tink the only way to achieve this is to use
> absolute paths for this helper-file. To make sur that I did
> understand what you mean: gconf.rpm contains a helper-file that
> includes the helper-macros we want to use in our specs.
> application.spec then contains a directive "inlcude gconf/helper-file"
> or something.
Yes, that could solve it, but I'm not sure if the rpm system allows for
includes. does it?
>
> I think something like
> %define gconfhelper /path/to/gconfhelper
> and then using %gconhelper
> should do the job. But this requires that /path/to/gconfhelper is
> known.
Yes, that it requires.. but that can well be %bindir as a script
included in the gconf package.
%gconfhelper () {
if [ -x %{_bindir}/gconftool-2 ]
then
unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
export GCONF_CONFIG_SOURCE=`%{_bindir}/gconftool-2
--get-default-source`
find %{_installdir} | grep "/etc/gconf/schemas" |while read F;
do
%{_bindir}/gconftool-2 --makefile-install-rule ${F}
done
fi
}
Something like that should work well enough?
//Spider
--
begin .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end
Attachment:
pgp1SGeFMEWJ9.pgp
Description: PGP signature