KDE/Meetings/Buildservice Projects

From openSUSE

Current Structure

• KDE:KDE3: KDE 3.x packages, usually in sync or slightly behind openSUSE:Factory
• KDE:Backports: KDE 3.x 3rd party applications, the openSUSE:Factory version backported to older distributions
• KDE:Community: KDE 3.x 3rd party applications currently maintained by somebody within the openSUSE community
• KDE:Qt: Qt 4.x packages as needed for KDE4 or other Qt 4.x based applications for all maintained distributions
• KDE:KDE4: KDE 4.x packages, KDE 4.x applications, all packages that are needed for building KDE 4.x. All of them usually slightly ahead of openSUSE:Factory

Current Problems

• There is no KDE 4.x Community project or a project for KDE 4.x backports
• Most people who package Qt 4.x related stuff link libqt4 from KDE:Qt, they do not aggregate it or build the repository against KDE:Qt
• There is no repository that just lists the needed packages for building KDE 4.x on your own
• There is no pattern that installs all packages necessary for building or developing KDE 4.x
• The sync of KDE:KDE4 with openSUSE:Factory is time-consuming work
• There is no Community repository for Qt 4.x or KDE 4.x addon packages
• There is only one project for KDE 4.x, not one for latest released stable (eg KDE 4.0.x) and one for development (eg KDE 4.1 Alpha)

Possible solutions

Plan A) make it modular

• KDE:KDE4:DEVEL: containing all packages needed to build KDE:KDE4, building against KDE:Qt
• KDE:KDE4:PLATFORM: containing KDE 4.x platform packages, building against KDE:KDE4:DEVEL
• KDE:KDE4: the latest version of KDE 4.x the desktop, building against KDE:KDE4:PLATFORM
• KDE:KDE4:APPS: joined repository of KDE 4.x 3rd party applications. Maintained by the openSUSE KDE Team, and people interested in providing packages can request a link being generated to their home directory.
• KDE:Qt:APPS: joined repository of Qt 4.x only applications. Maintained by the openSUSE KDE Team, and people interested in providing packages can request a link being generated to their home directory
• KDE:KDE4:PLATFORM:DEVEL: containing the packages needed to do your own KDE 4 development, building against KDE:KDE4:PLATFORM

pros/cons

• complicated structure, those who have used KDE:KDE4 in the past have to re-add the repository or switch to a different one
• With only KDE:*:Apps repository an user cannot chose in contrary to Backports v Community if he wants to trust only Novell KDE Team packages or everyone allowed to write in that repository/being linked in there

Plan B) the STABLE/UNSTABLE split

• KDE:KDE4:STABLE containing all packages needed by KDE4, KDE4 itself and apps building against it
• KDE:KDE4:UNSTABLE is the unstable variant of the packages.
• KDE:KDE3:STABLE / UNSTABLE: same split for KDE3
• community packages are either linked into STABLE or UNSTABLE (or forked between both)
• if community packages are aggregated into the tree, user can decide by package if they want to trust it or not

pros/cons

• osc history is lost during the manual "sync over new snapshot from KDE4:UNSTABLE to STABLE" process
• STABLE/UNSTABLE is not clearly defined: is a newer version more stable or less stable? is no change in the stable tree good or does it just mean that it is rotten and unused?
• changes from STABLE tree have to be manually merged with UNSTABLE
• osc (or the subversion model) is unsuited for branching

Plan C) It's just a pattern

• Everything in KDE:KDE4, with multiple patterns defined that classify:
  • Packages needed for building KDE4
  • KDE4
  • KDE4 app backports
  • KDE4 community addons

pros/cons

• just one repository: easy to overview, easy to add for users, simple
• many patterns: lots of choices for users who want the choice
• doesn't work right now, can only do one pattern per project (buildservice bug)
• double maintenance: patterns have to be manually maintained in addition
• community members have access to all packages, even those that are just backports from factory

Plan D) Split by dependencies

There will be 3 sets of repositories, depending on whether

• they build agains the plain distribution
• they need an updated Qt / KDE 4.0 platform (KDE4:STABLE)
• they need an updated Qt / KDE 4.1 platform (KDE4:UNSTABLE)

so the repository layout would be:

• KDE4:APPS
• KDE4:COMMUNITY
• KDE4:PLAYGROUND

building against plain distro

• KDE4:PLATFORM, containing the Qt version and the kde4 platform dependencies

for KDE4 "STABLE" (currently 4.0 RC2)

and the repositories building against it

• KDE4:DESKTOP
• KDE4:DESKTOP:APPS
• KDE4:DESKTOP:COMMUNITY
• KDE4:DESKTOP:PLAYGROUND

In addition, there will be an unstable branch of that in the future:

• KDE4:UNSTABLE:PLATFORM
• KDE4:UNSTABLE:APPS
• KDE4:UNSTABLE:COMMUNITY
• KDE4:UNSTABLE:PLAYGROUND

pros/cons

• con: user can not decide which KDE version he wants, KDE4:DESKTOP will be the one we consider stable, and UNSTABLE the next development version
• User might be confused to not have a toplevel Qt: repository to build against.