Project:KDE/Coding style

From Gentoo Wiki
Jump to: navigation, search

There are a number of rules and recommendations to follow when working on KDE-related packages. Following these will result in higher-quality ebuilds and reduce long-term maintenance burden.

Not all items discussed are KDE-specific, but they often come up and are always good to remember.

General policies

  • Please ask a member before adding the KDE project to your package.
  • Don't commit major bumps of core packages (such as KDE Applications 16.04 -> 16.08) directly to the tree. Spending some time in the overlay first will reduce the number of issues hitting the main tree.
  • Avoid major changes to KDE ebuilds in the tree. They should go into the overlay first, applied to either master and/or stable ebuild branches as appropriate.
  • USE flag defaults (IUSE="+useflag") should only be enabled for a good reason - such as it is commonly used, known to work and not pulling any dependencies. If in doubt, get a second opinion.
  • KDE-based applications should be in either SLOT 4 or 5, depending on what they are built upon. Feel free to fix packages that don't follow this, and don't forget to make the appropriate slotmove entry.
  • Use the latest EAPI. Older EAPIs are banned in the overlay and repoman is happy to let you know.

Using eclasses

All KDE packages should inherit one of two eclasses. kde4-base is the most common, for applications with the main CMakeLists.txt in the top level source directory. kde4-meta is used for applications that are part of a more complex source directory structure, such as repositories/tarballs that contain multiple applications.

  • Don't forget to the appropriate phase function (such as kde4-base_src_prepare) when overriding.
  • Always check for linguas and add them to the KDE_LINGUAS variable.
  • Double check handbook support in your package - check doc/, doc/$PN and similar for .docbook files. To enable handbook support, set KDE_HANDBOOK="optional" (if possible) or KDE_HANDBOOK="always".

Patches

We prefer to keep as close to upstream as possible, however there are a number of cases when we might want to carry a patch:

  • Distribution specific changes (such as supporting a slotted dependency).
  • Workarounds for bad bugs (to improve the user experience where an upstream fix is not yet available).
  • Backporting upstream fixes for bugs where we do not want to wait for the next release.

Most patches should go upstream. They can give feedback to improve the patch, everyone else will benefit, and we will reduce our maintenance burden. The preferred method is requesting review on Phabricator or Review Board.

Feel free to ask for assistance with the upstreaming process. A number of project members can also assist with committing and editing upstream bugs once the review has been approved.

Overlay

  • Always run repoman full on the ebuild subtree you're working on before committing anything.
  • Always use repoman commit when committing ebuilds. It will ensure your manifests are updated, and report any QA issues you might have forgotten about.
  • Packages in the overlay should be KDE-related in some way.
  • Try to keep one commit per change if possible. If more appropriate - one commit per feature.
  • All commit messages must look like this:
CODE
<category/pn>: <summary of changes>

<Optional detailed description of changes>

for example:

CODE
kde-frameworks/extra-cmake-modules: drop dev-qt/qtcore RDEPEND
    
This was added in 83cadfedf9a2af7934f5456ab818c16ad5a1edf3 as certain modules
call qmake, but is now causing an unnecessary dependency as some consumers do
not use these modules and do not require qt at all.
    
Gentoo-bug: 572652
  • If you change ebuild names in kde-base, synchronize those changes in the following locations if applicable and run regenerate-files:
    • sets/
    • Documentation/package.keywords/
    • Documentation/package.unmask/
Any changes made elsewhere will be lost in next regenerate-files tool run.

Bugzilla

There are a number of conventions used to help keep track of our bugs.

  • Watch out for bugs filed in the KDE component, as this bypasses bug wranglers and the package might have a different maintainer.
  • Bugs concerning the overlay should have their summary prefixed with [kde overlay].
  • Bugs that have fixes present in the overlay should be marked IN_PROGRESS, have the InOverlay keyword added, and kde overlay present in the whiteboard field.
  • It's useful to put fixed in <version> in the whiteboard field of bugs that were fixed by upstream

QA

  • Ensure that DEPEND and RDEPEND are always correctly separated. It may help to add COMMON_DEPEND if needed.
  • Keep ebuilds clean, look at recommended ebuild formatting rules below (mandatory for kde-* categories). Use existing ebuilds (like kdelibs) for reference.
  • Sort dependencies alphabetically - it makes it easier to manage them later
CODE
>=app-misc/strigi-0.6.3[dbus,qt4]
dev-libs/libpcre
dev-libs/libxml2
  • Put blocks at the begin of RDEPEND section, !useflag? ( ) preferably before useflag? ( ) - it's easier to spot them when they're in expected location.
CODE
RDEPEND="${DEPEND}
	!kdeprefix? ( !dev-libs/libconvert )
"
  • Put optional dependencies after obligatory ones - again - improves readability.
CODE
x11-proto/renderproto
xinerama? ( x11-proto/xineramaproto )
  • Avoid single line expressions - they are utterly unreadable
CODE
ssl? ( dev-libs/openssl )
zeroconf? (
	|| (
		net-dns/avahi[mdnsresponder-compat]
		!bindist? ( net-misc/mDNSResponder )
	)
)
  • Always indent dependencies with tab characters from new line (including other variable like ${COMMON_DEPEND} may be exception here) and always break line *after* dependency - it makes it easier to synchronize such deps semi-automatically between ebuilds using GUI diff/merge tools (less conflicts). The same applies to PATCHES as well.
CODE
COMMON_DEPEND="
	>=app-misc/strigi-0.6.3[dbus,qt4]
"
# sth? ( dev/foo ) - re-add when in tree
DEPEND="${COMMON_DEPEND}
	doc? ( app-doc/doxygen )
	nls? ( virtual/libintl )
"

PATCHES=(
	"${FILESDIR}/dist/09_disable_debug_messages_if_not_explicitly_enabled.patch"
	"${FILESDIR}/dist/20_use_dejavu_as_default_font.patch"
	"${FILESDIR}/dist/23_solid_no_double_build.patch"
)
CODE
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
    <maintainer type="project">
        <email>kde@gentoo.org</email>
        <name>Gentoo KDE Project</name>
    </maintainer>
</pkgmetadata>
  • Blockers added after upstream package changes or package splits should be maintained for 2 major versions. For example, we support a smooth upgrade from 4.5 to 4.7, but not 4.5 to 4.8