Custom Query (344 matches)

There are some programs that provide debug packages (those ending with -debug). These packages are meant to contain .dbg files for each .exe and .dll` file which are the extraction of the HLL debug info from the executable.

The current scheme of creating these packages is inconsistent: on one hand it implicitly creates .dbg files for each .exe/.dll of each RPM that is built, on the other hand the package maintainer needs to manually add the respective sub-pkckage directives to the .spec file.

This needs to be sorted out and automated as much as possible.

Currently, for many packages the logic of obtaining the sources to build the package is like this:

1. Take the original vendor source archive.
2. Generate an OS/2 diff from SVN/GIT between the corresponding vendor branch and the corresponding revision of the trunk.
3. Apply the diff to the source tree from 1.
4. Pack the archive from 1. and the diff from 2. in the source RPM.

This approach has several problems:

1. You need to find and download the right source archive and generate the right diff each time you want to make a new RPM package. This is kind of double work since both the source and the diff are already in the repo, matched and merged.
2. The information about the exact SVN/GIT commit the sources are taken from is lost. This makes it hard to tell which state of the source tree the given RPM release represents. It's therefore easy to mess things up when there are too many packages to maintain.

I have a better solution which I already tested on a small which package. In short, the logic looks like this:

1. Add two variables to .spec: svn_url and svn_rev which point to the correct SVN branch and revision of the source tree to build (including all necessary OS/2 patches etc).
2. In the %prep section, check for the presence of the ZIP with the given revision in SRCS and if not there, check it out right from SVN, then pack and put to SRCS.
3. Proceed further as usual.

For GIT, use a similar logic but with the appropriate variables git_url and git_commit and respective commands.

This way, no duplication takes place, no manual work is needed and it's always clear which revision the given RPM represents. This simplifies package managing a lot.

The .spec code for this is very simple, these are the corresponding parts from http://trac.netlabs.org/rpm/browser/spec/trunk/SPECS/which.spec?rev=429 which may be used as a template:

%define svn_url     http://svn.netlabs.org/repos/ports/which/trunk
%define svn_rev     733

Source: %{name}-%{version}-r%{svn_rev}.zip

%prep
%if %(sh -c 'if test -f "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip" ; then echo 1 ; else echo 0 ; fi')
%setup -q
%else
%setup -n "%{name}-%{version}" -Tc
svn export -r %{svn_rev} %{svn_url} . --force
rm -f "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip"
(cd .. && zip -SrX9 "%{_sourcedir}/%{name}-%{version}-r%{svn_rev}.zip" "%{name}-%{version}")
%endif

I suggest to use this approach for all programs for which we maintain a SVN or a GIT repo (i.e. everything from ​http://trac.netlabs.org/ports/, for instance).

I'm working on updating the bootstrap packages for i686 and pentium4. All works well, except that at the beginning of the bootstrap console, after a long (really long) delay, the following is thrown:

rpmdb: __fop_file_setup:  Retry limit (100) exceeded
error: cannot open Sigmd5 index using db3 - File exists (17)

Note that my changes have had no bearing on the above; I get that error just using the pentium4 1.5 bootstrap with no changes. I've tried updating rpm, rpm-libs, urpo, gettext (newer rpm needs intl8), but I'm still missing something to update rpm fully, so I haven't tested whether rpm 4.8.1 might resolve the above. There seems to be something broken in the db laid down from the bootstrap, though.

After the delay and the error, yum install yum now works as expected, and after a reboot, we have a working i686 (or pentium4) setup. The delay is annoying, though. Any thoughts?