KDE SC 4 packaging policies — различия между версиями

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Adopted KDE Packaging Policy)
 
 
(не показана 1 промежуточная версия 1 участника)
Строка 33: Строка 33:
 
</pre>
 
</pre>
  
{{warning|KDE have many modules that at first sight for new packagers looks like a library. You usually can find it in %_kde_libdir/kde4. They '''are not''' libraries at all, are dynamic loading modules, and:
+
{{Предупреждение|KDE have many modules that at first sight for new packagers looks like a library. You usually can find it in %_kde_libdir/kde4. They '''are not''' libraries at all, are dynamic loading modules, and:
 
* Should not need ldconfig
 
* Should not need ldconfig
 
* Must go together with main application subpackage, not split into separate library package}}
 
* Must go together with main application subpackage, not split into separate library package}}
Строка 205: Строка 205:
 
<hr>
 
<hr>
  
{{message|This Policy is based on the [http://wiki.mandriva.com/en/KDE_SC_4_packaging_policies Mandriva KDE SC 4 packaging policies].}}
+
{{Примечание|This Policy is based on the [http://wiki.mandriva.com/en/KDE_SC_4_packaging_policies Mandriva KDE SC 4 packaging policies].}}
[[Category:Packaging Policies]]
+
[[Категория:Packaging Policies]]
 
+
== Package application naming ==
+
All application packages (or subpackages) should have exactly the same name as they have in their 'main' package, e.g.:
+
* okular - Coming from package kdegraphics and splitted
+
* akregator - Coming from package kdepim and splitted
+
* konversation - Coming from their own package konversation
+
 
+
== Library policy ==
+
'''Every''' library should be split in a package with proper soname. There is a common complain to have too many subpackages, but this is just a excuse for laziness.
+
Some reasons behind splits:
+
* Developers need to change soname and binary api. If we a have library inside a package, upgrade would be hard
+
* Legacy applications should need the library only, no the whole package. If we decide to install an application like {{pkg|akregator}} only, there is no reason to have the whole {{pkg|kdepim}} package installed
+
* Development packages can require only library subpackages, not the whole package.
+
 
+
Package '''should not''' require libraries explicitly. Rpmbuild in ROSA sets all necessary dependencies automatically.
+
 
+
How does this look like in a spec file following the standard ROSA style?
+

Текущая версия на 14:24, 30 мая 2012


Package application naming

All application packages (or subpackages) should have exactly the same name as they have in their 'main' package, e.g.:

  • okular - Coming from package kdegraphics and splitted
  • akregator - Coming from package kdepim and splitted
  • konversation - Coming from their own package konversation

Library policy

Every library should be split in a package with proper soname. There is a common complain to have too many subpackages, but this is just a excuse for laziness. Some reasons behind splits:

  • Developers need to change soname and binary api. If we a have library inside a package, upgrade would be hard
  • Legacy applications should need the library only, no the whole package. If we decide to install an application like akregator only, there is no reason to have the whole kdepim package installed
  • Development packages can require only library subpackages, not the whole package.

Package should not require libraries explicitly. Rpmbuild in ROSA sets all necessary dependencies automatically.

How does this look like in a spec file following the standard ROSA style?

%define kfoo_major 1
%define libkfoo %mklibname kfoo %{kfoo_major}

%package -n %libkfoo
Summary: Kfoo library
Group: System/Libraries

%description -n %libkfoo
Kfoo library.

%files -n %libkfoo
%defattr(-,root,roo,-)
%_kde_libdir/libkfoo.so.%{kfoo_major}*
Dialog-warning.png
Предупреждение

KDE have many modules that at first sight for new packagers looks like a library. You usually can find it in %_kde_libdir/kde4. They are not libraries at all, are dynamic loading modules, and:

  • Should not need ldconfig
  • Must go together with main application subpackage, not split into separate library package

Patch policy

Every patch for a kde package MUST have this header :

#
# Description: 
# Forwarded: 
# Bug: 
# Author: 
#

Basic requires for every common KDE 4 application

  • kdelibs4-devel

Configure and building with one line ( be free from auto*hell )

Since start of KDE 4, the cmake build utility was adopted. Cmake is a good easy text base build utility that provides common ways to make out of the source buildings. With kde4-macros package, we provide a common framework to make the most complex build in kde4 easy.

So, to build a kde4 package, you will need just this in %build section:

%build
%cmake_kde4
%make

If you need debug packages, just define _with_debug=1 in the rpm command line or bm. We strongly recommend use bm tool to build your specs.

bm -l --define _with_debug=1

SPEC defines provided by kde4-macros

Macro Value Description
%_kde_prefix /usr Main prefix for kde applications
%_kde_libdir %_kde_prefix/%_lib Library directory
%_kde_iconsdir %_kde_prefix/share/icons Icons directory
%_kde_sysconfdir %_sysconfdir System configuration directory
%_kde_datadir %_kde_prefix/share Common data dir for kde
%_kde_configdir %_kde_datadir/config kde config dir
%_kde_appsdir %_kde_datadir/apps Application specific dir
%_kde_docdir %_kde_prefix/share/doc Documentation dir
%_kde_bindir %_kde_prefix/bin Binary dir
%_kde_sbindir %_kde_prefix/sbin SBinary dir
%_kde_includedir %_kde_prefix/include Include dir
%_kde_mandir %_kde_prefix/share/man Man dir for kde
%_kde_autostart %_kde_prefix/share/autostart Autostart
%_kde_services %_kde_prefix/share/kde4/services Sycoca services
kde_servicetypes %_kde_prefix/share/kde4/servicetypes Service mimes

SPEC Layout

This is kind of controversial for many old school packagers, but the nested layout style was adopted since some time and proves to be more efficient in big packages for edit. The basic idea is, all subpackages have all related entries nested in one block on their spec, instead of havin all definitions, then all descriptions, then all post/postun sections then the files sections. In the template below we show an package kmanyfoo, which have two apps and one library.

Template

Name:          kmanyfoo
Summary:       K Desktop Environment
Version:       4.0.70
Group:         Graphical desktop/KDE
License:       GPL
URL:           http://www.kde.org
Release:       1
Source:·       ftp://ftp.kde.org/pub/kde/stable/%version/src/kfoo-%version.tar.bz2
BuildRequires: kdelibs4-devel
BuildRequires: desktop-file-utils
Requires:      kfooblue
Requires:      kfoored

%description 
- kmanyfoo is a kfoo metapackage for all kfoo applications

# we let the files section empty or with a README to assure package is generated. 
# If the main package is just a convenience main description and don't need a meta pack, we even don't need this section
%files

#------------------------------------------------------

%package kfooblue
Summary: KFoo Blue package
Group: Graphical desktop/KDE

%descriton kfooblue
KFoo Blue package

%files kfooblue
%defattr(-,root,root,-)
%_kde_bindir/kfooblue
%_kde_libdir/kde4/bluemodule.so
%_kde_appsdir/kfooblue
# You don't need made all iconspaths explicit, use glob
%_kde_iconsdir/*/*/*/kfooblue.* 

#------------------------------------------------------

%package kfoored
Summary: KFoo RED package
Group: Graphical desktop/KDE

%descriton kfoored
KFoo RED package

%files kfoored
%defattr(-,root,root,-)
%_kde_bindir/kfoored
# You don't need made all iconspaths explicit, use glob
%_kde_iconsdir/*/*/*/kfoored.* 
%_kde_servicesdir/kfoored.desktop

#------------------------------------------------------

%define kfoo_major 1
%define libkfoo %mklibname kfoo %{kfoo_major}

%package -n %libkfoo
Summary: Kfoo library
Group: System/Libraries

%description -n %libkfoo
Kfoo library.

%post -n %libkfoo -p /sbin/ldconfig
%postun -n %libkfoo -p /sbin/ldconfig

%files -n %libkfoo
%defattr(-,root,root,-)
%_kde_libdir/libkfoo.so.%{kfoo_major}*

#------------------------------------------------------

%prep
%setup -q 

%build 
%cmake_kde4
%make

%install
rm -fr %buildroot
make -C build DESTDIR=%buildroot install



%check
for f in %{buildroot}%{_kde_datadir}/applications/kde4/*.desktop ; do
     desktop-file-validate $f
done 


Idea.png
Примечание
This Policy is based on the Mandriva KDE SC 4 packaging policies.