Project:KDE/Frameworks

KDE Frameworks 5 (KF5) is the next major release of the KDE libraries. The major focus is refactoring, which will allow applications to make use of KDE libraries without having to depend on large packages like kdelibs. Some code was even migrated upstream to Qt 5, which frameworks depends upon.

All Gentoo support for KF5 is in KDE overlay. Already packaged modules available with @kde-frameworks-live set.

High level overview
KDE libraries are split into individual frameworks organised in tiers. Tier 1 libraries may only depend on Qt frameworks or other system libraries. Tier 2 libraries may only depend on tier 1 libraries, Qt frameworks or other system libraries, and so on. KDE workspaces build upon frameworks to provide the user environment. KDE applications build upon frameworks and workspace to complete the picture.

In order to match the distinct three-way upstream categorisation, we will introduce three new categories: kde-frameworks, kde-workspace, and kde-apps. As individual upstream projects move to frameworks, we too will move them to kde-apps, eventually leaving kde-base empty.

We will introduce at least one new eclass (kde-frameworks) in order to make a clean break from the old eclasses, which have accumulated a lot of legacy code over time. Depending on how frameworks, workspaces, and applications are eventually released, it may prove useful to maintain individual eclasses (perhaps with a base common eclass) for each of the three to keep things simple.

Todo

 * Urgent - patch kde4-meta.eclass to use KDE/4.x branch for kde-workspace 9999 ebuilds, as master will soon be KF5 ✅
 * Tests are optional to build, but dependencies required for them are still pulled in. The add_subdirectory entry for autotests should just be commented out when tests are disabled. tests/ and examples/ should always be removed. ✅
 * Create a new or update existing bump script for releases ✅
 * Follow up test failures with upstream
 * Review local coinstallability changes eg. many binaries are renamed upstream, but we still install everything into a custom directory ✅
 * Audit which packages have tests and add FRAMEWORKS_TEST="false" as appropriate ✅
 * Some frameworks with X USE flag now have runtime detection. Drop USE flag where appropriate, and look at porting the dep checks upstream away from deprecated HAVE_X11 (which unconditionally requires xproto and libX11) to the specific header

Blockers

 * Naming scheme - kde-workspace master will become KF5 soon, breaking all -9999 overlay ebuilds from that repo
 * Parallel installation (kde-base/kdelibs and kde-frameworks/* naturally collide)
 * Qt 5 in the tree
 * New eclass approval
 * New category approval

Naming scheme
We need to determine how to handle live ebuilds as repositories slowly move to KF5 in master. Currently, we hack the eclass for force -9999 to use the last 4.X branch.

Ideas:


 * Remove hacks so each version directly tracks the appropriate upstream branch again. Update sets to pull in the appropriate version. We already do this for releases, eg. @kdebase-4.13 pulls in @kdebase-workspace-4.11


 * Create a fake 4.9999 branch for a consistent version:

Current scheme:
 * 4.x.49.9999 (KDE/4.x branch)
 * 9999 (master aka KDE/4.x+1)

Example new scheme:
 * 4.x.49.9999 (KDE/4.x branch)
 * 4.9999 (latest KDE/4 branch if master is migrated to KF5, otherwise master)
 * 9999 (master)

The naming scheme 4.x.49.9999 was used because upstream names prereleases of 4.x as 4.(x-1).60 through 4.(x-1).98 (depending on the number of alpha, beta, and rc releases).

Everything
All implementation details should be discussed to ensure we implement the best solution.