Projects/KDE on Solaris/FOSS specfiles: Difference between revisions
(Initial whack at how FOSS spec files are configured. Needs work) |
(clean up code sections since wiki tried to translate unintentionally) |
||
| Line 22: | Line 22: | ||
typically, an apply_patches script has something like: | typically, an apply_patches script has something like: | ||
#!/bin/sh | <nowiki>#!/bin/sh | ||
for file in \ | for file in \ | ||
configure.diff \ | configure.diff \ | ||
| Line 31: | Line 31: | ||
do | do | ||
gpatch -p1 Solaris/diffs/$file | gpatch -p1 Solaris/diffs/$file | ||
done | done</nowiki> | ||
I convert it to read: | I convert it to read: | ||
#!/bin/sh | <nowiki>#!/bin/sh | ||
N=0 | N=0 | ||
for file in \ | for file in \ | ||
| Line 53: | Line 53: | ||
echo "Patch${Y}:\t\t%{patchprefix}-${NM}.${N}.diff" >> patchlist | echo "Patch${Y}:\t\t%{patchprefix}-${NM}.${N}.diff" >> patchlist | ||
echo "%patch${Y} -p1" >> patching | echo "%patch${Y} -p1" >> patching | ||
done | done</nowiki> | ||
what this does is move all the files into a more "orderly" list | what this does is move all the files into a more "orderly" list | ||
| Line 61: | Line 61: | ||
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 | %define patchprefix %{src_name}-%{src_ver} | ||
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 | every time we uprev a package. 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. | ||
Revision as of 05:24, 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 containing 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 NM=`echo $file | sed 's\.diff$,,'` # in case there's a trailing index value we want to remove... NM=`echo ${NM} | sed 's,\.[0-9]*$,,'` N=`echo ${N} | awk '{printf "%.02d",$1+1}'` # strip off preceding 0 for the %patch command Y=`echo ${N} | sed 's,^0,,'` mv $file Mypkg-1.0.1-${NM}.${N}.diff echo "Patch${Y}:\t\t%{patchprefix}-${NM}.${N}.diff" >> patchlist 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. 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.
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 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.