| 167 | == Taking sources from source repositories == |
| 168 | |
| 169 | It's a common practice that the program sources to build the RPM packages are taken from a tarball (referred to by the `Source:` keyword in the `.spec` file) which is provided by the program vendor and then stored in the source RPM. It works fine when the packages are built from the vendor sources w/o any modifications but this is rarely a case on OS/2. On OS/2, we don't push our patches upstream (for many reasons) and instead host our own repositories for programs that we support where we manage our patches (many of the programs are located here: http://trac.netlabs.org/ports/). |
| 170 | |
| 171 | Given this, using the tarball approach on OS/2 requires to pull a set of patches from our own source repository and apply it to the vendor's tarball to make the program work on OS/2 each time a new change is made. This requires a lot of manual work and is very inconvenient when dealing with a large number of packages. For this reason, it is strongly recommended to write `.spec` files that download the sources directly from the source repositories rather than use tarballs and patch files. This may be achieved with a very simple block of commands. |
| 172 | |
| 173 | Note that one should not worry too much about the network speed and traffic issues when using this approach since the sources are downloaded only once for each given repository revision; any subsequent attempt to build a package form the same revision will simply use the source ZIP created when the revision is fetched for the first time w/o involving any network connection. There is also a possibility to use local working copies to fetch the sources from instead of online repositories (see below). |
| 174 | |
| 175 | === SVN === |
| 176 | |
| 177 | The snippets below assume our http://trac.netlabs.org/ports/ source repository layout. They are taken from this real-life [http://trac.netlabs.org/rpm/browser/spec/trunk/SPECS/libtool.spec?rev=471 spec file]. |
| 178 | |
| 179 | Paste this block after the main keyword block and before the `%description` field for the main package: |
| 180 | {{{ |
| 181 | %define svn_url http://svn.netlabs.org/repos/ports/libtool/trunk |
| 182 | %define svn_rev 891 |
| 183 | |
| 184 | Source: %{name}-%{version}%{?svn_rev:-r%{svn_rev}}.zip |
| 185 | |
| 186 | BuildRequires: gcc make subversion zip |
| 187 | }}} |
| 188 | |
| 189 | Paste this block instead of the usual `%prep / %setup / %patch` sequence: |
| 190 | {{{ |
| 191 | %prep |
| 192 | %if %{?svn_rev:%(sh -c 'if test -f "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip" ; then echo 1 ; else echo 0 ; fi')}%{!?svn_rev):0} |
| 193 | %setup -q |
| 194 | %else |
| 195 | %setup -n "%{name}-%{version}" -Tc |
| 196 | svn export %{?svn_rev:-r %{svn_rev}} %{svn_url} . --force |
| 197 | rm -f "%{_sourcedir}/%{name}-%{version}%{?svn_rev:-r%{svn_rev}}.zip" |
| 198 | (cd .. && zip -SrX9 "%{_sourcedir}/%{name}-%{version}%{?svn_rev:-r%{svn_rev}}.zip" "%{name}-%{version}") |
| 199 | %endif |
| 200 | }}} |
| 201 | |
| 202 | In order to use the working copy instead of the URL (useful for creating test packages during development) one modifies the first snippet to something like this: |
| 203 | {{{ |
| 204 | %define svn_url D:/Coding/ports/libtool/trunk |
| 205 | #%define svn_rev 891 |
| 206 | }}} |
| 207 | |
| 208 | Note the commented out `svn_rev` variable — this causes the local changes from the working copy to be picked up. If `svn_rev` is not commented out then the specified revision w/o any local modifications will be used (the same way as when giving an URL; the only difference is that no network connection is required given that the specified revision is already contained in the working copy). |
| 209 | |