[Rpm-maint] spec file unification across distributions
Stanislav Brabec
sbrabec at suse.cz
Tue Jun 24 13:22:32 UTC 2008
Hallo.
Even if RPM packages may be compatible across distributions, it is not
possible to say the same for spec files. Each distribution uses
different macro set and different conventions. As a result, spec files
cannot be shared across distributions.
I would like to start a discussion about unification of spec files,
which should introduce compatible spec file conventions.
My first mail starts with comparing of basic conventions of openSUSE and
Fedora. It's still far from being complete. Some things regarding Fedora
or upstream RPM may be even outdated.
External links:
openSUSE packaging http://en.opensuse.org/Packaging
Fedora packaging https://fedoraproject.org/wiki/Packaging/Guidelines
Higher level solutions built on top of RPM
Official openSUSE solution is ZYPP: http://en.opensuse.org/Libzypp
RPM patches
openSUSE uses patched rpm, which does some things differently. For example:
- safely removes $RPM_BULD_ROOT
- %makeinstall uses DESTDIR
- openSUSE supports Recommends:, Supplements:, Enhances:, Suggests:
- ...
Spec files
Preamble
openSUSE still use PreReq, Fedora uses newer Requires(pre) (note:
Requires(posttrans) is even not yet implemented).
Macros
Here is a set of macros defined in /usr/lib/rpm/suse_macros:
%restart_on_update
%stop_on_removal
%configure_kernel_source
%run_permissions
%run_suseconfig_fonts
%suse_update_config
%suse_update_libdir
%fillup_and_insserv
%do_real_fillup
%add_start_if_needed
%insserv_cleanup
%fillup_only
%rc_fillup
%sysc_fillup
%save_rc_config_d_was_in_filelist
%insserv_force_if_yast
%supplements_kernel_module
For guessing openSUSE version, strings %suse_version and %sles_version
exist.
Sysconfig
openSUSE uses a special way to maintain sysconfig files. All sysconfig
files must have a special sysconfig comments for sysconfig editor.
Scripts
GConf:
openSUSE and Fedora use three scriptlets to perform the update. As the
update process combining old and new instance scriptlets is very
fragile, they are incompatible and clean cross-distro update is
impossible.
http://en.opensuse.org/SUSE_Build_Tutorial/GConf_scriptlets
On my opinion, Fedora's scriptlets may break in case of package rename
and merge of two packages into one. openSUSE seems to survive it.
Texinfo:
openSUSE and Fedora do the same, but openSUSE defines macros %
install_info and %install_info_delete.
Actually used scriptlets are fragile and in some situations they keep
unwanted orphans or delete wanted items.
Scrollkeeper:
Fedora uses scriptlets to perform scrollkeeper-update. openSUSE has
patched scrollkeeper/rarian and can live without scriptlets here.
desktop-database:
openSUSE has a SuSEconfig script. SuSEconfig is called after every
installation and updates desktop database. SuSEconfig is deprecated in
openSUSE, but reverting to RPM based solutions means editing of
hundreds of spec files and ~30000% performance loss in a worst case.
Fedora calls update-desktop-database from scriptlets. As it calls all
scriptlets at the end of a big transaction, calling it 300 times at
once is a bit faster.
SuSE uses %suse_update_desktop file a lot in %install phase. It provides
a way to control contents of desktop files.
mimeinfo:
Both Fedora and openSUSE use nearly the same scriptlets, which do the same.
Use of RPM based solutions means about ~2000% performance loss in a
worst case here.
GTK+ icon cache:
openSUSE uses SuSEconfig script. SuSEconfig is called after every
installation and updates GTK+ icon cache. Reverting to RPM based
solutions means editing of hundreds of spec files and ~30000%
performance loss in a worst case.
Fedora calls it at the end of the transaction many times at
once. Peformance loss is not as bad here, because subsequent runs
reuse file system cache and run faster. Fedora's use of touch seems to
be obsolete nowadays (fixed in upstream).
Fonts:
openSUSE has %run_suseconfig_fonts and a a SuSEconfig script conditionally
called after every installation. Reverting to RPM based solutions would
mean a hour or more of installation time in a worst case on slow
machines.
Fedora calls it at the end of the transaction many times at
once. Peformance loss is not as bad here, because subsequent runs
reuse file system cache and run faster.
Shared libraries:
openSUSE and Fedora do the same (including the tricky way), but
several openSUSE packages still use deprecated %run_ldconfig.
Initscripts Conventions:
openSUSE has macros doing stuff in a very similar way altogether with
fillup:
%fillup_and_insserv
%insserv_only
%stop_on_removal
%restart_on_update
The bad thing is the fact, that it may fail badly in case of package
rename. To fix this failure, a new RPM feature may be needed.
User and group handling:
Both use a very similar approach, but I think there is no convention.
The bad thing is the fact, that calling userdel is unsafe and may fail
badly for a similar reasons like init scripts.
libexecdir:
Fedora allows /usr/libexec.
/usr/libexec is not allowed in openSUSE, --libexecdir=%{_prefix}/lib/%{name} is
preferred. But openSUSE %configure still uses buggy --libexecdir=%{_libdir} and
each package has to set it explicitly.
https://bugzilla.novell.com/show_bug.cgi?id=157894
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec at suse.cz
Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz/
More information about the Rpm-maint
mailing list