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