PaulHowarth/Blog/2008-03-10

Monday 10th March 2008

Local Packages

  • Built bw-whois for perl 5.10.0 on Fedora 9

  • Updated dovecot to 1.0.13

  • Built perl-Crypt-GPG for perl 5.10.0 on Fedora 9

  • Updated perl-FileHandle-Unget to fix license tag

  • Updated perl-FileHandle-Unget 0.14 packages for Red Hat Linux 9, Fedora Core 1, Fedora Core 2, and Red Hat Enterprise Linux 3 to current packaging standards (will build on Fedora 9, license tag fixed, dist tag fixed, etc.); current versions of perl-FileHandle-Unget won't build on these old distributions

  • Fixed perl-Jcode to build successfully on Fedora 9 (buildreq perl(Test::More))

  • Built perl-Mail-SRS for perl 5.10.0 on Fedora 9

  • Built perl-Net-CIDR for perl 5.10.0 on Fedora 9

  • Built perl-Sendmail-AccessDB for perl 5.10.0 on Fedora 9

  • Built perl-Sys-Hostname-Long for perl 5.10.0 on Fedora 9

  • Built perl-Test-Prereq for perl 5.10.0 on Fedora 9

  • Built perl-Text-Diff for perl 5.10.0 on Fedora 9

  • Updated python-twisted-core to build on Fedora 9 with egg-info file

From Fedora 9, python packages include an egg-info file that is installed directly under %{python_sitelib} or %{python_sitearch} for architecture-independent and architecture-specific packages respectively. This can present a problem when trying to maintain a single spec file that can be used to build a package for multiple target distribution releases. The approach taken in the official Fedora package for python-twisted-core is to use a distribution-based conditional in the %files list:

%files
...
%if 0%{?fedora} >= 9
  %{python_sitearch}/Twisted-%{version}-py2.5.egg-info
%endif

I'm not keen on this approach because it requires the presence of the %{fedora} macro to build successfully on Fedora 9 onwards (not a bad assumption really since it is defined from a file included in the fedora-release package, which everyone will have), but more importantly it will require a further edit to support different distributions such as Red Hat Enterprise Linux 6 when that appears. My preferred approach is to test directly for the actual significant differences between releases that affect a package, and handle things according to the results of this testing. This leads to a more portable source package. My approach to the egg-info issue in python-twisted-core is to check to see if an egg-info file has been generated, and include it in the %files list if present:

%install
...
# See if there's an egg-info file
if [ -f %{buildroot}%{python_sitearch}/Twisted-*.egg-info ]; then
        echo %{buildroot}%{python_sitearch}/Twisted-*.egg-info |
                sed -e 's|^%{buildroot}||'
fi > egg-file

%files -f egg-file


Recent