Difference between revisions of "Solaris/FOSS specfiles"

Jump to: navigation, search
(<nowiki> != <code>)
(Cleaning up)
Line 2: Line 2:
 
from Stefan Teleman's KDE4 on Solaris porting effort located on cvsdude.com.
 
from Stefan Teleman's KDE4 on Solaris porting effort located on cvsdude.com.
 
(http://kdesolaris.svn.cvsdude.com).  The tarballs are almost always a relative
 
(http://kdesolaris.svn.cvsdude.com).  The tarballs are almost always a relative
directory starting with Solaris/, and containing patch, configure, build, and install scripts, as well as patches, and any custom files needed to build a module.
+
directory starting with Solaris/, and contain patch, configure, build, and install scripts, as well as patches, and any custom files needed to build a module.
  
 
However, they are difficult to deal with, and regenerating them is a bit of
 
However, they are difficult to deal with, and regenerating them is a bit of
Line 44: Line 44:
 
     somecfile.h.diff
 
     somecfile.h.diff
 
do
 
do
 +
# Strip off the trailing ".diff"
 
NM=`echo $file | sed 's\.diff$,,'`
 
NM=`echo $file | sed 's\.diff$,,'`
 +
#
 
# in case there's a trailing index value we want to remove...
 
# in case there's a trailing index value we want to remove...
 +
# so if the file was configure.01.diff, NM sees configure.01,
 +
# and what we really want is "configure".
 
NM=`echo ${NM} | sed 's,\.[0-9]*$,,'`
 
NM=`echo ${NM} | sed 's,\.[0-9]*$,,'`
 +
#
 +
# just a counter so we can build the patchlist for the spec file,
 +
# and we match it to the patch, so it's really clear which patch
 +
# it should be
 +
#
 
N=`echo ${N} | awk '{printf "%.02d",$1+1}'`
 
N=`echo ${N} | awk '{printf "%.02d",$1+1}'`
# strip off preceding 0 for the %patch command
+
#
 +
# strip off preceding 0 for the %patch and Patch${Y} commands
 
Y=`echo ${N} | sed 's,^0,,'`
 
Y=`echo ${N} | sed 's,^0,,'`
 +
#
 +
# rename the file to something more "unique"
 +
#
 
mv $file Mypkg-1.0.1-${NM}.${N}.diff
 
mv $file Mypkg-1.0.1-${NM}.${N}.diff
 +
#
 +
# Create the patchlist entry for this patch.
 +
#
 
echo "Patch${Y}:\t\t%{patchprefix}-${NM}.${N}.diff" >> patchlist
 
echo "Patch${Y}:\t\t%{patchprefix}-${NM}.${N}.diff" >> patchlist
 +
#
 +
# Create the patching entry for this patch (%prep area)
 +
#
 
echo "%patch${Y} -p1" >> patching
 
echo "%patch${Y} -p1" >> patching
 
done</code>
 
done</code>
Line 61: Line 80:
 
b) the section above %prep, is where you will insert "patchlist"
 
b) the section above %prep, is where you will insert "patchlist"
 
Above patchlist, you
 
Above patchlist, you
%define patchprefix %{src_name}-%{src_ver}
+
<code>%define patchprefix %{src_name}-%{src_ver} </code>
 
so we don't have to care about changing the stupid patch file names
 
so we don't have to care about changing the stupid patch file names
every time we uprev a package.  It also makes it dead simple to copy
+
every time we uprev a package.
existing patches from a previous revision for a new one and tune those
+
 
patches for the next revision. To understand this value, I was able to
+
There are a couple of reasons we do this:
use this method to uprev gstreamer-0.10.17 to gstreamer-0.10.22 iteratively
+
1) patches must have unique names because they are copied to packages/SOURCES
in less that 2 hours. I got stuck at 0.10.23 since that wanted glib2-2.14
+
2) when we up rev a package, we don't lose the ability to build a
and FOSS at that time only had glib2-2.12.12
+
  previous revision of the package, without some "mecurial" magic.
 +
3) a patch has been submitted the pkgbuild repo to allow the
 +
  patch mechanism to use relative paths to patches, which means
 +
  that patches/<PKG NAME>/<SRC VER>/patchname.diff. Eventually,
 +
  this means that spec/patches won't have to be a dumping ground
 +
  for all patches.
 +
 
 +
It also makes it dead simple to copy existing patches from a previous revision for a new one and tune those patches for the next revision. To understand this value, I was able to use this method to uprev gstreamer-0.10.17 to gstreamer-0.10.22 iteratively in less that 2 hours. I got stuck at 0.10.23 since that wanted glib2-2.14 and FOSS at that time only had glib2-2.12.12
  
 
c) in the %prep section, include "patching" file from above.
 
c) in the %prep section, include "patching" file from above.
Line 83: Line 109:
 
All your new patches should go in spec/patches/%{src_name}/%{src_ver}
 
All your new patches should go in spec/patches/%{src_name}/%{src_ver}
 
and then symlink those into spec/patches.
 
and then symlink those into spec/patches.
 
The reason for doing this is very simple. This project is so complex
 
with so many working parts, that it's impossible (unless you are truly
 
a Mercurial *guru*) for normal folks to go back to a previous instance.
 
  
 
Using a very simple %if clause, a spec file can now support multiple
 
Using a very simple %if clause, a spec file can now support multiple

Revision as of 15:47, 3 December 2009

Currently, solaris.bionicmutton.org/SRC contains tarballs that originate from Stefan Teleman's KDE4 on Solaris porting effort located on cvsdude.com. (http://kdesolaris.svn.cvsdude.com). The tarballs are almost always a relative directory starting with Solaris/, and contain patch, configure, build, and install scripts, as well as patches, and any custom files needed to build a module.

However, they are difficult to deal with, and regenerating them is a bit of a PITA, and pretty much makes working on KDE4 an exclusive club with secret handshake and associated drama.

Starting in the kde4-specs-440 tree, there is an effort going on to convert all those modules from the DUDE tarball, to a purely spec format. Due to the fact that the FOSS modules are built for both 32-bit and 64-bit, there are two components minimum to each module.

1) FOSS<modulename>.spec - this contains all the high level information, with package name, version, description, license, package dependencies, and a package list. Any new modules or updated modules should include a explicit package list, so that changes between versions of packages can be tracked. Globals in the plist is just sloppy, but I understand why it happens.

2) base-specs/base-<module>.spec - this contains pretty much what was found in the DUDE Solaris tarball (typically Solaris-PGKNAME-REVISION,MINORREV.tar.gz). Decomposing a Solaris tarball should go something like this:

a) extract all the patches. prefix them with the packagename-version, postfixed with an index starting at 01, and ending in .diff

typically, an apply_patches script has something like: #!/bin/sh for file in \

    configure.diff \
    config.h.diff \
    Makefile.diff \
    somecfile.c.diff \
    somecfile.h.diff

do

    gpatch -p1 Solaris/diffs/$file

done

I convert it to read:

#!/bin/sh N=0

  for file in \
    configure.diff \
    config.h.diff \
    Makefile.diff \
    somecfile.c.diff \
    somecfile.h.diff

do

  1. Strip off the trailing ".diff"

NM=`echo $file | sed 's\.diff$,,'`

  1. in case there's a trailing index value we want to remove...
  2. so if the file was configure.01.diff, NM sees configure.01,
  3. and what we really want is "configure".

NM=`echo ${NM} | sed 's,\.[0-9]*$,,'`

  1. just a counter so we can build the patchlist for the spec file,
  2. and we match it to the patch, so it's really clear which patch
  3. it should be

N=`echo ${N} | awk '{printf "%.02d",$1+1}'`

  1. strip off preceding 0 for the %patch and Patch${Y} commands

Y=`echo ${N} | sed 's,^0,,'`

  1. rename the file to something more "unique"

mv $file Mypkg-1.0.1-${NM}.${N}.diff

  1. Create the patchlist entry for this patch.

echo "Patch${Y}:\t\t%{patchprefix}-${NM}.${N}.diff" >> patchlist

  1. Create the patching entry for this patch (%prep area)

echo "%patch${Y} -p1" >> patching done

what this does is move all the files into a more "orderly" list with a created patchlist that can be imported into the base-spec file, as well as the patching order.

b) the section above %prep, is where you will insert "patchlist" Above patchlist, you %define patchprefix %{src_name}-%{src_ver} so we don't have to care about changing the stupid patch file names every time we uprev a package.

There are a couple of reasons we do this: 1) patches must have unique names because they are copied to packages/SOURCES 2) when we up rev a package, we don't lose the ability to build a

  previous revision of the package, without some "mecurial" magic.

3) a patch has been submitted the pkgbuild repo to allow the

  patch mechanism to use relative paths to patches, which means
  that patches/<PKG NAME>/<SRC VER>/patchname.diff. Eventually,
  this means that  spec/patches won't have to be a dumping ground
  for all patches.

It also makes it dead simple to copy existing patches from a previous revision for a new one and tune those patches for the next revision. To understand this value, I was able to use this method to uprev gstreamer-0.10.17 to gstreamer-0.10.22 iteratively in less that 2 hours. I got stuck at 0.10.23 since that wanted glib2-2.14 and FOSS at that time only had glib2-2.12.12

c) in the %prep section, include "patching" file from above. Additionally, include the configure.sh, converting most ${} variables to %{} variables, unless they are truly shell variables.

d) in the %build section, import build.sh. clean it up

e) in the %install section, import install.sh, clean it up. This section is usually trickiest because of the way 32 and 64 bit binaries get made, and how some packages have a hard time honoring the configured paths.

All your new patches should go in spec/patches/%{src_name}/%{src_ver} and then symlink those into spec/patches.

Using a very simple %if clause, a spec file can now support multiple revisions, with all the behavior customized off that specific version to include package requirements, explicit plists, patches, applying patches, configure changes, etc. It takes a little bit more effort than just chopping up a spec file because a bunch of stuff changed.


Content is available under Creative Commons License SA 4.0 unless otherwise noted.