Re: Moving to a more distro/host agnostic setup for the canonicalspec files.
- From: Christian Lohmaier <cloph cup uni-muenchen de>
- To: gnome-packaging-list gnome org
- Subject: Re: Moving to a more distro/host agnostic setup for the canonicalspec files.
- Date: Sun, 12 Jan 2003 13:04:05 +0100
Hi,
On Sat, Jan 11, 2003 at 08:37:22PM +0100, Spider wrote:
>
> *) only depending on auto-dependency tracking is in my idea a "bad"
> choice. having at least the general package interdepencencies set hard
> in the .spec are good for giving other packagers a general view on what
> depends on what.
This is ok for me as well. But at least there should be official
package-names for all parts that make up gnome.
> *) Generalized handling of source locations. .spec allows you to
> specify where to get the source from, with a ftp url.. Thats another
> nice thing to have ;)
:-) But when building the rpm, the tarball is not fetched from the given
location (you can do that of course), instead your defined
rpm-source-dir is searched for a match.
> Gconf and schema installations are another thing that might need a good
> overview
These are handled pretty well in some packages: (install only, don't
know how to deinstall gconf-stuff):
during %install one can do a
export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
and during %post one could do the 'real' thing:
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
for SCHEMA in %{_sysconfdir}/gconf/schemas/{schema1,schema2}.schemas; do
gconftool-2 --makefile-install-rule $SCHEMA
done
Note that for this the person who installs the package must set his
rpm_install_path to include the bindir to gconftool (eg.
/opt/gnome2/bin). An alternative would be (like I did in the packages
build for my Caldera- to specify %{_bindir}/gconftool-2 ..
I don't really know which of these is the better solution.
> scrollkeeper is also an issue for some, since scrollkeeper modifies the
> installed files so they no longer match md5sums, makes for an issue with
> some packaging formats. how can that be handled nicely in rpm's .spec?
yes, theres a %verify(options) attribute that is meant to be placed in
the %files section:
one can check owner, group, mode, md5, size, maj, min, symlink, mtime.
so one could e.g. specify
%verify(owner group) file
to check only for owner and group of the file or in turn use
%verify(not owner group) file
to check everything but owner and group
> General packaging guidelines? are there any? How do we as the Gnome
> project want the distributors to treat Gnome packages?
No, there's a lack of those. I personally would like to use FHS (where
this applies), e.g prefix would be /opt/gnome2, sysconfdir
/etc/opt/gnome2,...
> The gconf schema interpretions might be necessary to make a general
> "Gnome .spec" macro for, since they do require some trickery, the
> default process is to violate the building system, and then force itself
> down into the deep recesses of the packagers discretion to find exactly
> what schema files are installed during the process.
That's right, but since I always did a fake install to see if every file
that is meant to be installed is really in the %files section this has
not really been a plus in effort.
> (that behaviour is bad for actions such as "rpm -tb <some.tar.bz2>")
Not if the spec-file is created correctly. Why would a
"rpm -ba specfile" work better than a "rpm -tb tarball"?
> 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?
I already use a ~/.rpmmacros file so that I don't have to set Packager
or Distribution manually and I use different 'presets' that I use for
gnome-packages (prefix set to /opt/gnome2 ...) and for regular packages
(prefix is /usr).
Just appending these Macros to this file is enough to make use of them...
But maybe I got you wrong.
ciao
Christian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]