Re: Creating .spec files



Hi James,

On Mon, Dec 08, 2003 at 11:12:31AM -0600, James Richardson wrote:
> I'm in the process of putting together some spec files for some gnome 
> apps, but i'm curious on how to handle the scrollkeeper documentation.

Scrollkeeper is a beast ;->
You should make sure that you did specify you omf-file (if it's not in the
default list)
--with-omfdirs=/usr/share/omf:/usr/local/share/omf:/opt/gnome2/share/omf:/opt/gnome/share/omf:/opt/kde/omf

You have to specify all omf-dirs you want, the internal lists gets overvritten
with that flag.
(You can of course edit %sysconfdir/scrollkeeper.conf afterwards as well)

> I'm definining %{localstatedir}  to /var/lib per the "GNOME RPM spec 
> file packaging guidelines" [ 
> http://www.fedora.us/docs/rpm-packaging-guidelines.html ]

Did not know of this guideline before, but a few remarks from my very
personal point of view. I basically agree, but there are points where my
optionion differs:

1) Defining directories in the spec-file sucks.

> . Also making 
> sure to use their %install method and %build methods

2) Defining default configure parameters like --prefix, --sysconfdir,..
   and Optflags manually sucks.

> [as i've read on 
> some mailing lists that the scripts aren't really portable or just doing 
> a make DESTDIR=blah install dosen't garuntee it'll get get installed in 
> the right place....

3) using manual make install sucks.
4) listing *.mo files manually sucks.

> The gnome packages that do include scrollkeeper docs/omf fles install 
> files into /var/lib/scrollkeeper/<lang>/<xmlfile>. Why is this? 

They don't. Scrollkeeper generates these. The xml-files are
scrollkeeper's content lists (cl).

> When you 
> go to install another package, those files are "owned" by a previous 
> package that installed those.

The previously installed package is buggy. It should not contain these
files.

> Is there a ./configure flag i'm missing to not install those?

That would be something like --dont-run-scrollkeeper-update or
something, but I don't such flag exists (but it is not necessary
anyway).

I don't want to complain about the guideline without commenting on the
points I dislike.

1) Hard-Coded directories are evil.

I want to have gnome installed in /opt/gnome2 /etc/opt/gnome2 and
/var/opt/gnome2
Specifying the directory in the spec-file causes manual work for me.
On how to handle this another way, please read on.

2/3) a manual ./configure --<parameters>/ manual make sucks.

It maybe the case that the %configure and %make macros are not part of
the basic rpm distribution, but there's no big deal in creating a
~/.rpmmacros file that contains the macro.
Why is there a dedicated packaging project if your main concern is that
everybody can build the rpms by him/herself? The goal should be to
provide the ready-made packages. If someone really wants to compile
everything on his/her own, there's no problem in creating the
~/.rpmmacros file since then there probably will be more than one
package that gets build.
You can define "Packager" and the path-settings in that file as well, so
Problem 1) is solved with this approach as well.
The other concern that many gnome-programs install things in
include/something is mainly historical or did never exist at all. I
did install gnome 1.2(or was it 1.4) with
--includedir=/opt/gnome/include (Caldera distro) and now gnome 2.4 in
/opt/gnome2/include and never had problems with missing/not found
includes. Guess what pkgconfig is for.
The same accounts for %makeinstall or %makeinstall_std (the latter
expands to make DESTDIR=$RPMBUILDROOT install)

4) manually listing .mo files sucks...
...since there is the handy %find_lang macro that does this job.

So what else to consider:
The mentioned packageconfig files need a distinct location with manual
override (since there is no problem with manually moving the files why
bother with non-existing configure-options): /usr/lib/pkgconfig
Gconf likes to write in the real directory (where the Packager as regular user
doesn't have write permission, but there's a nice solution for that- no reason
to unset the export statement since every section runs in its own subshell.
so the %install section contains the following in my dummy-spec:

#########
%install
rm -rf $RPM_BUILD_ROOT
#export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
%makeinstall
%find_lang %{name}
# pkg-config should only have one home.. since many distributions put this in /usr
# and I don't want to add the PKG_CONFIG_PATH everytime, move all the .pc files in that
# location
if [[ -d $RPM_BUILD_ROOT%{_libdir}/pkgconfig && %{_libdir} != "/usr/lib" ]] ; then
        mkdir -p $RPM_BUILD_ROOT/usr/lib/pkgconfig
        mv $RPM_BUILD_ROOT%{_libdir}/pkgconfig/* $RPM_BUILD_ROOT/usr/lib/pkgconfig
        # rmdir to make files-section easier (use wildcards)
        rmdir $RPM_BUILD_ROOT%{_libdir}/pkgconfig ;
fi
########

Now that the registration of gconf-entries was disabled, we have to take care
of it after installation of the spec-file. Note that I use
%{_bindir}/gconftool-2 and not only gconftool-2 since I think that the user
that wants to install the package will not add /opt/gnome2/bin (my bindir used
to build the package) to rpm's install_script_path. For the end-user this
approach is easier but less portable (gconf has to be compiled with the same
bindir as $package to be installed).
You'll see that I got %_install_info and %_remove_install_info macros that do
the dirty work. 
########
%post
#check whether %{_libdir} is in /etc/ld.so.conf, if not, add it...
if (! grep -qx %{_libdir} /etc/ld.so.conf ); then
        echo "Adding %{_libdir} to /etc/ld.so.conf"
        echo "Please make sure to add %{_bindir} to your PATH"
        echo %{_libdir} >> /etc/ld.so.conf
fi
/sbin/ldconfig
# %_install_info
#export GCONF_CONFIG_SOURCE=`%{_bindir}/gconftool-2 --get-default-source`
#for SCHEMA in %{_sysconfdir}/gconf/schemas/{schema1,schema2}.schemas; do
#%{_bindir}/gconftool-2 --makefile-install-rule $SCHEMA
#done
#########

Just my 2ct
ciao
Chrsitian
-- 
NP: Metallica - Master Of Puppets



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]