From Mageia wiki
Revision as of 07:27, 31 March 2016 by Marja (talk | contribs) (add Note about KF5 (Plasma5) policy)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Note:
This page is old, but kept because we still have KDE4 in stable. For Plasma5 / KF5 please check KF5 packaging policy


KDE Team

Nickname Mail Name Time zone
anaselli anaselli (at) mageia (dot) org anaselli UTC+1
dmorgan dmorgan (at) mageia (dot) org Dexter
mikala mikala (at) mageia (dot) org John UTC-3
schultz watersnowrock (at) gmail (dot) com Donald

Note: Changes/commits in Qt/KDE related packages by NON-kde packagers need to be reviewed and approved by the kde team or some representative.

Meetings

Proposed: Every wednesday (set meeting hour)


Proposals

  • Have someone elected (or by other decision) to represent the team in any other meeting or place (council)
  • Define strict rules about package naming (for example for library packages use only underscore _ instead a regular trace - )
  • Rules about major changes
  • Have a season for bug hunting and tests in cauldron (and commits are only done in a time defined by the team)
  • Have a season to dedicate to Mageia 1 (backports,updates) with also a time defined for commits
  • etc.

All these proposals are to be updated/changed and exist to keep the team tuned and syncronized.


Goals

  • Switch to plasma kdm for Mageia 2
  • Rework task- packages
  • kill empty packages (kdegraphics, kdeedu etc etc )
  • ....

Qt/KDE Packaging Policy

We decided try at most make some standards for upcoming KDE SC 4 packaging, so any newcomer in Mageia tools and packaging will have some template to follow and some standard rules to follow as well.

WARNING: valid for Qt/KDE related packages.


Package application naming

In the past, we use to have nomenclatures like kdebase-konsole, kdegraphics-kpdf, etc..

All applications package ( or subpackage ) naming now should be exactly the same name as their main binary. Ex:

  • 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 splitted with their proper soname. There's usual 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 have library inside package, upgrade would be hard
  • Legacy applications should need the library only, not the whole package. If we decide install an application like akregator only, theres no reason to have whole kdepim package installed
  • Development packages can reeuiqres just library packages, not the whole package.

Package should not requires libraries explicitely. Mageia RPM build already set the necessary dependencies automatically

How it will be on spec file using standard Mageia 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
%_kde_libdir/libkfoo.so.%{kfoo_major}*

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:

  • Should not need ldconfig
  • Must go together with main application subpackage, not splitted nor in a 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

Check that your spec & packages generated match the Mageia policy

Please also install rpmlint-mageia-policy package to check your spec, the src.rpm & the binary generated

rpmlint kmanyfoo.src.rpm
rpmlint kmanyfoo-1.1.mga1.i586.rpm
rpmlint libkmanyfoo1-1.1.mga1.i586.rpm
rpmlint kmanyfoo.spec

Errors found by rpmlint need to be fixed because the package even if it's build won't be upload by our Build System

SPEC defines provided by kde4-macros

macro path description
%_kde_prefix /usr Main prefix for kde applications
%_kde_libdir %{_kde_prefix}/%{_lib} Library directory
%_kde_sysconfdir %{_sysconfdir} System configuration directory
%_kde_datadir %{_kde_prefix}/share Common data directory
%_kde_configdir %{_kde_datadir}/config Config directory
%_kde_appsdir %{_kde_datadir}/apps Application specific directory
%_kde_applicationsdir %{_kde_datadir}/applications/kde4 KDE 4 application specific directory
%_kde_docdir %{_kde_datadir}/doc Documentation directory
%_kde_mandir %{_kde_datadir}/man Manual directory
%_kde_iconsdir %{_kde_datadir}/icons Icons directory
%_kde_bindir %{_kde_prefix}/bin Binary directory
%_kde_sbindir %{_kde_prefix}/sbin SBinary directory
%_kde_includedir %{_kde_prefix}/include Include directory
%_kde_autostart %{_kde_datadir}/autostart Autostart directory
%_kde_services %{_kde_datadir}/kde4/services Sycoca services
%_kde_servicetypes %{_kde_datadir}/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 by some stubborn packagers ( mostly this one who is kindly writing for you now ) 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 having 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
Group:         Graphical desktop/KDE
Version:       4.0.70
Release:       %mkrel 1
License:       GPLv2
URL:           http://www.kde.org
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 doesn't need a meta pack,
we don't even need this section
%files

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

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

%description kfooblue
KFoo Blue package

%files kfooblue
%_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

%description kfoored
KFoo RED package

%files kfoored
%_kde_bindir/kfoored
# You don't need made all iconspaths explicit, use glob
%_kde_iconsdir/*/*/*/kfoored.* 
%_kde_services/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.


%files -n %libkfoo

%_kde_libdir/libkfoo.so.%{kfoo_major}*

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

%prep
%setup -q 

%build 
%cmake_kde4
%make

%install
%makeinstall_std -C build 



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

This page is available under the Creative Commons Attribution-ShareAlike 2.5 License

Authors

  • Helio Chissini de Castro
  • Gustavo Pichorim Boiko
  • Nicolas Lécureuil
  • Markus Espunkt
  • Daniel Kreuter
  • Rémy Clouard