begin quote
On Sun, 12 Jan 2003 13:04:05 +0100
Christian Lohmaier <cloph cup uni-muenchen de> wrote:
... message edited to be sparse....
> > *) only depending on auto-dependency tracking is in my idea a "bad"
> > choice.
> This is ok for me as well. But at least there should be official
> package-names for all parts that make up gnome.
Okay, that I agree with, and I say "go for the names of the tarballs"
also see the apt-rpm point in other message.
> > *). where to get the source from, with a ftp url..
> :-) 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.
Yes, of course, but since the .spec allows us to have this information
it would be a bad idea not to provide it, since a user of a .rpm might
want to update, looks in the rpm -q gconf2 , finds that it is in
ftp://ftp.gnome.org/pub..../ and thus has a simple way to check for
updates, even if he built it with rpm -tb or other way... Information
is good.
> > 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
Well, thats just it, it has to be handled well in -all- packages :-)
<SNIP>
> 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.
This is where we could provide our own macros, but those cannot be
distributed separately, since a .spec in a tarball must depend on
something else in that case. And we dont want to make everyone who uses
rpm -tb <> to install our custom scripts, or configure their system in
a special way. Thats bad practice.
Can we also make sure that our .spec's follow the FHS?
> > scrollkeeper is also an issue for some.
>
> 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
So we would assure the %verify(not size not md5 not mtime) for all the
scrollkeeper generated parts? thats an okay solution, I think.
> > 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,...
This is something we need to put together, preferrably :)
>
> > 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.
Yes, but when a package maintainer updates/adds a .schema, can we make
it work or will the .spec be broken for the first package release
afterwards until we get bugreports?
>
> > (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"?
Not really, but all .spec's arent well-written, that was my point :)
Lots have changed since the pre-2.0 days when I was one of those who
wrote and verified .specs, I know.. but burned child... ya, whatever :)
>
> > 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 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.
Well, you got me wrong, since that would require that anyone who wants
to use the simplicity of rpm -tb <tarball> would have to include our
"helper" macros into their ~/.rpmmacros ... not a good solution.
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?
> ciao
toodles ;)
//Spider
For reference: heres what I hacked up for Gentoo to use with .spec
installation
gnome2_gconf_install() {
if [ -x ${ROOT}/usr/bin/gconftool-2 ]
then
unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
export GCONF_CONFIG_SOURCE=`${ROOT}/usr/bin/gconftool-2
--get-default-source`
einfo "installing gnome2 gconf schemas"
cat ${ROOT}/var/db/pkg/*/${PN}-${PVR}/CONTENTS | grep
"obj /etc/gconf/schemas" | sed 's:obj \([^ ]*\) .*:\1:' |while read F;
do
echo "DEBUG::gconf install ${F}"
${ROOT}/usr/bin/gconftool-2
--makefile-install-rule ${F}
done
fi
# schema installation
}
--
begin .signature
This is a .signature virus! Please copy me into your .signature!
See Microsoft KB Article Q265230 for more information.
end
Attachment:
pgpZtnKSKASPm.pgp
Description: PGP signature