SUSE Package Conventions/Specific Packages

Эта статья содержит фрагменты на иностранном языке. Вы можете помочь переведя её до конца. (cм. руководство по переводу)

10. Специфичные пакеты
Назад		Далее

Содержание

1 Специфичные пакеты

Специфичные пакеты

Пакеты GTK+ и GNOME

Данный раздел описывает особенности сборки GTK+ и GNOME пакетов в SUSE Linux. После вступления с базовой информацией, идет описание более сложных и менее общих возможностей, а именно: Gconf, GStreamer registry и общая база данных MIME.

Определены следующие базовые правила:

Крайне не рекомендуется использовать GTK+ версии 1.x, везде где это возможно следует использовать версию 2.x.
GTK+ and GNOME–based libraries (optionally also applications) should use the same prefix as GTK+/GNOME itself. This helps to prevent prefix clashes. The prefix is currently /opt/gnome, but it will change to /usr in the future. There are few exceptions where files must be explicitly moved to /usr. See 10.1.3, "Shared MIME Info".

According to FHS, configuration files must be located below /etc/opt/gnome and variable data below /var/opt/gnome if the the prefix is /opt/gnome.

GTK+-related -devel packages should be in the RPM group Development/Libraries/X11. GNOME related -devel subpackages packages should be in the group Development/Libraries/GNOME. Both GTK+ and GNOME–related packages providing the parts of libraries needed at runtime should be in the group System/Libraries. The GNOME desktop packages should be in the group System/GUI/GNOME. Finally, the GTK+ and GNOME–related applications should be in a respective subgroup of Productivity.

The packages needed for build must be mentioned in the BuildRequires tag, dependencies are solved automatically. Two meta packages are defined: gtk2-devel-packages and gnome2-devel-packages, which can be listed in the BuildRequires tag. They substitute for packages needed for compilation of packages based on GTK+ 2.x and GNOME 2.x. The meta package gnome2-devel-packages includes only core libraries, including libgnomeprint, but not less common libraries, like gnome-panel, vte, and gail. Some other packages that are required at runtime but not for building are also not included, for example, some gdk-pixbuf loaders, fonts, and font database configuration.

Most GTK+ and GNOME packages use the standard configure, make, and make install technique. It is usually enough to set the right paths with configure options but no other special actions are necessary to locate GTK+ and GNOME. In this way, it is similar to other packages.

The related part of the spec file typically looks like:

%build
%suse_update_config -f
CFLAGS="$RPM_OPT_FLAGS” \
./configure --prefix=/opt/gnome \
        --libdir=/opt/gnome/%_lib \
        --sysconfdir=/etc/opt/gnome \
        --localstatedir=/var/opt/gnome
make

%install
make DESTDIR=$RPM_BUILD_ROOT install

In the example above, see how the $RPM_OPT_FLAGS are usually passed to configure. Also see that the macro %suse_update_config is usually called to update some auto-stuff related files.

Many GNOME packages use helper scripts or binaries installed in the libexec directory. They must call --libexecdir=/opt/gnome/lib/{name} where {name} usually is the package name. lib is used instead of %lib. See 4.1, "Biarch Systems" for more details. The configure options usually look like:

./configure --libdir=/opt/gnome/%_lib \
            --libexecdir=/opt/gnome/lib/%{name} \
            [...]

Packages providing GNOME applets can use --libexecdir=/opt/gnome/lib/gnome-applet. The directory is reserved for these applets.

All applications should install a .desktop file to define a menu entry. They must call the macro %suse_update_desktop_file for all installed menu entries in the %install section. This typical example is taken from the package planner:

%install
[...]
%suse_update_desktop_file %name Office ProjectManagement

Language-specific files (localizations of menu entries, messages, help content, etc.) should be marked with the respective %lang tag in the file list. There is the macro %find_lang for this purpose. It is typically used the following way:

%install
[...]
%find_lang %name

%files -f %{name}.lang
[...]

GConf

see Packaging/Scriptlet_Snippets#GConf

Общие данные MIME

see Packaging/Scriptlet_Snippets#mimeinfo

Данные MIME в GNOME

Older GNOME packages use mime-info for MIME type definitions. Such MIME types are not recognized by new version of GNOME. The package needs shared-mime-info, too. This feature is used when the package installs files in /opt/gnome/share/mime-info. If there are no files in /usr/share/mime or /opt/gnome/share/mime, the shared-mime-info must be generated from mime-info. See also Section 10.1.3, "Shared MIME Info".

The conversion can be done either by the script mime-info-to-mime provided by the package shared-mime-info, it can be called the following way in the %install section:

%install
[...]
DESTDIR=$RPM_BUILD_ROOT mime-info-to-mime

Or if the command fails, the generated files $RPM_BUILD_ROOT/usr/share/mime/packages/*.xml need to be manually edited. The fixed files are usually added to the package as an extra source and installed in the %install section. This example is taken from the package file-roller:

Source1:      file-roller.xml
[...]

%install
[...]
mkdir -p $RPM_BUILD_ROOT/usr/share/mime/packages
cp %{S:1} $RPM_BUILD_ROOT/usr/share/mime/packages

Finally, the new files must be listed in the %files section and the Shared MIME database must be updated in the %post and %postun scripts. See previous section.

10.2. Kernel Modules

Detailed information about the kernel can be found at http://www.suse.com/~agruen/KMPM/.

Added info 2009-09-26: This page only mentions that the info can be found at http://developer.novell.com/wiki/index.php/Kernel_Module_Packages_Manuals now.

Perl Modules

This section describes how Perl modules are packaged on SUSE Linux. The following rules are defined:

Each Perl module should be in a separate package.
The package name should be perl-XXX, where XXX is the original name of the source tarball, as obtainable at http://cpan.perl.org/by-module/XXX, except that the levels are separated by hyphens rather than slashes or double colons). See also Section 1.5, "Name Tag". (FIXME: this link is broken, as are most other internal links in this guide)
The RPM group should be Development/Libraries/Perl (unless it is at an application level package, in which case it might be Productivity/*)
The package should require Perl of the same version as was used for build. The macro %perl_version serves this purpose.

A dependency on Perl modules is not detected automatically. This means the packages must mention the necessary Perl modules in the Requires tag. This applies to the dependency between Perl modules as well.

The package perl and Perl modules should be mentioned in the BuildRequires tag.

This example of a typical spec file preamble comes from the package perl-Inline-CPR:

# norootforbuild
 # usedforbuild    ... perl perl-Inline perl-Parse-RecDescent ...
 
 
 Name:         perl-Inline-CPR
 License:      Artistic License
 Group:        Development/Libraries/Perl
 Version:      0.12
 Release:      151
 Autoreqprov:  on
 Requires:     perl = %{perl_version}
 Requires:     perl-Inline
 BuildRequires:	perl ... ????FIXME (the following section explains this tag, making the reader expect an example here) 
 Summary:      Write Perl subroutines in C
 URL:          http://cpan.org/modules/by-module/Inline
 Source:       Inline-CPR-%{version}.tar.bz2
 Patch:        Inline-CPR-%{version}.diff
 BuildRoot:    %{_tmppath}/%{name}-%{version}-build
 
 %description
 This module allows you to program C in perl. See also perl-Inline.
 
 
 Authors:
 --------
     Brian Ingerson <INGY@cpan.org>

In the example above, see that two other Perl modules are needed for build and at run-time. They are mentioned by the BuildRequires tag and the package perl-Inline is mentioned by the Requires tag. The second package perl-Parse-RecDescent need not be mentioned by the Requires tag because it is required already by perl-Inline.

Most Perl modules are built and installed a standard way. In addition, the macros %perl_make_install, %perl_process_packlist, %perl_vendorarch, and %perl_vendorlib are available. This makes it extremely easy to create a package. This approach is also used in the package perl-Inline-CPR from the example above. Here is the rest of its spec file:

%prep
%setup -n Inline-CPR-%{version}
%patch

%build
perl Makefile.PL
make
make test

%install
%perl_make_install
%perl_process_packlist

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-, root, root)
%doc Changes README MANIFEST
%{perl_vendorlib}/Inline/CPR*
%{perl_vendorarch}/auto/Inline/CPR
/var/adm/perl-modules/%{name}

In the example above, see how the macro %perl_process_packlist is used. It removes $RPM_BUILD_ROOT from some files and allows packing the file %perl_archlib/perllocal.pod as /var/adm/perl-modules/%{name}. See Section 3.15, "%perl_process_packlist" for more details.

SuSEconfig --module perl should be called after installing the package. It updates the %perl_archlib/perllocal.pod from the information saved in /var/adm/perl-modules. It is not called from the %post script because it would take ages if several packages are installed at once and each of them called this script independently.

If a module includes a part written in C, the $RPM_OPT_FLAGS can usually be passed the following way. The example is taken from the package perl-Bit-Vector:

%build
perl Makefile.PL OPTIMIZE="$RPM_OPT_FLAGS -Wall"
make
make test

10.4. Python Modules

Примечание: While generally true, this description is outdated in a number of subtle ways. Please refer to Python packaging guidelines for a more up-to-date policy.

This section describes how Python modules are packaged on SUSE Linux. The following rules are defined:

Each Python module should be in a separate package.
The package name should be python-XXX. See also Section 1.5, "Name Tag".
The RPM group should be Development/Libraries/Python.
The package should require Python of the same major version as was used for build. This avoids problems when upgrading Python. The macro %py_requires exists for this purpose. See how it is used in the example below.
BuildArch generally must not be noarch

The packages python and python-devel are usually needed to build. They need to be defined in the tag BuildRequires.

This example of a typical spec file preamble comes from the package python-numeric:

 # norootforbuild
 
 Name:           python-numeric
 BuildRequires:  python-devel
 Summary:        A Numerical Extension to Python
 Version:        24.2
 Release:        5
 %define tarname Numeric
 Source0:        %{tarname}-%{version}.tar.bz2
 License:        BSD, Python
 Group:          Development/Libraries/Python
 URL:            http://sourceforge.net/projects/numpy
 Autoreqprov:    on
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
 
 %py_requires
 
 %description
 Numerical Python adds a fast and compact multi-dimensional array
 language facility to Python.
 
 Authors:
 --------
     numpy-developers@lists.sourceforge.net

Most Python modules use distutils now, so it is extremely easy to package them. This feature is documented at http://www.python.org/sigs/distutils-sig/. It is also used in the package python-numeric from the example above. Here is the rest of its spec file:

%prep
%setup -n Numeric-%{version}
%patch

%build
export CFLAGS="$RPM_OPT_FLAGS"
python setup.py build

%install
python setup.py install --root=$RPM_BUILD_ROOT \
                        --prefix=%{_prefix} \
       --record-rpm=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)
%doc README changes.txt Demo

In the example above, see how the variable $RPM_OPT_FLAGS is usually used to build binaries. Also see in the install command that the option --record-rpm can be used to create a file list that is then used in the %files section. This feature currently exists only in SUSE Python packages. A patch for upstream is waiting for review.

If a package uses a nonstandard build method, the special RPM macros %py_ver, %py_incdir, %py_libdir and %py_sitedir can be used to get the location of Python directories.

This example is taken from the package python-fcgi:

Source0:      http://alldunn.com/python/fcgi.py
[...]

%prep

%build

%install
install -m755 -d $RPM_BUILD_ROOT/%{py_sitedir}
install -m644 %{S:0} $RPM_BUILD_ROOT/%{py_sitedir}
python%{py_ver} %{py_libdir}/compileall.py -d %{py_site}/ \
   $RPM_BUILD_ROOT/%{py_sitedir}

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
%{py_sitedir}/fcgi.py*

10.4. KDE 3.x Packages

For the beginning packager, a KDE packaging cookbook gives step by step instructions on how to package KDE apps.

A typical spec file for a KDE package looks like the following:

# norootforbuild


 Name:           knutclient
 Version:        0.9.3
 Release:        3
 License:        GPLv2
 URL:            http://www.foo.org
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
 BuildRequires:  kdelibs3-devel update-desktop-files
 Source:         %{name}-%{version}.tar.bz2
 Requires:       nut
 Group:          Hardware/UPS
 Summary:        NUT GUI Interface

 %description
 Knutclient is a GUI interface for UPS system NUT
 

 Authors:
 --------
     john.doe@foo.org

The only KDE-specific thing in the heading is kdelibs3-devel in BuildRequires. This package is needed to build all KDE packages. There are couple of exceptions (e.g. kicker addons) which need a more specific development packages, for example kdebase3-devel or kdepim3-devel.

 %prep
. /etc/opt/kde3/common_options
 %setup -n %{name}-%{version} -q
update_admin

The file /etc/opt/kde3/common_options sets all the environment variables and flags to the correct values needed for compiling KDE applications. Do not at any time redefine $KDEDIR, $QTDIR etc as you may be used to doing when hand-compiling KDE.

update_admin is a shell macro that updates the admin dir of the package to the latest version from the kdelibs3-devel package. This initializes the (autotools) build system and will switch (depending on the distribution you build for) to unsermake as the default build tool.

If the package you're trying to build does not work with unsermake and it is not possible to fix that, you can use the --no-unsermake parameter to update_admin to force it use regular automake.

 %build
 . /etc/opt/kde3/common_options
 ./configure $configkde
 do_make %{?jobs:-j%jobs}

You have to source common_options again, this time to get the correct $RPM_OPT_FLAGS for the build phase. The $configkde variable contains all the right flags for a common ./configure call. It also adds --enable-final for newer distributions. This speeds compile time by concatenating all .cpp files into one and compiling them as one. If your package does not work with --enable-final, and it is not possible to fix that, you can add a --disable-final after $configkde to switch the default again.

'do_make' will call either make or unsermake depending on the way update_admin was called.

 %install
 . /etc/opt/kde3/common_options
 do_make DESTDIR=$RPM_BUILD_ROOT $INSTALL_TARGET
 %suse_update_desktop_file %name System Monitor
 %find_lang %name
 kde_post_install

The only custom macro here is kde_post_install. It does a couple of uninteresting things, like marking installed desktop files for translation or moving crystalsvg icons into hicolor, so that they're accessible from non-KDE desktops as well. It should always be the last nonstandard line in your %install section.

 %clean
 rm -rf "$RPM_BUILD_ROOT"

Standard %clean section.

 %files -f %name.lang
 %defattr(-,root,root)
 %doc README AUTHORS ChangeLog COPYING INSTALL
 /opt/kde3/bin/*
 /opt/kde3/share/apps/knutclient
 /opt/kde3/share/icons/??color
 /opt/kde3/share/applnk/Utilities/knutclient.desktop
 /opt/kde3/share/locale/*/LC_MESSAGES/*.mo
 /opt/kde3/share/doc/HTML/??/knutclient/*

This is a standard %files section, referencing the typical KDE application's structure of supporting files.

Назад		Далее
9. Меню рабочего стола	В начало	Список изменений RPM(changelogs)