[Kde-scm-interest] Package splitting

[Thiago Macieira]

Em Terça-feira 26. Janeiro 2010, às 01.39.36, Troy Unrau escreveu:
> Feedback requested. Thiago told me that ossi has already brought this
> up somewhere, but I haven't grepped through the archives yet.

Here's a suggestion on how splitting could work.

Disclaimer: I am not satisfied that splitting is the way to go.

Remember that the objective here is to have a simple dependency-management 
system. It must be resolvable by humans (not scripts or machines) and it must 
forbid any loops.

IF we split the KDE repositories into one per app, we'll have hundreds of them 
(I estimate about 700). It's VERY, VERY easy to produce loops. The end result 
would be a GNOME-style mesh of dependencies, which make building very hard. 
Remember that's why Patrick Volkerding stopped packaging GNOME on Slackware.

Anyway, my suggestion is to have each repository tagged in two levels: 
category and stage. The category is a logical group that the repository 
belongs. The stage is one of "libs", "release", "review" and "playground".

The build rules are:
1) "KDE Support" comes first

2) "KDE Base" comes second

3) within each category, libs comes first

4) everything else is build-order independent (that is, must not depend on)

So a sample structure is like follows (FAQ below):

Category: KDE Support
 - libs
	Qt
	QCA
	Soprano
	Akonadi
	Strigi
	Taglib
 - release
	Oxygen Icons
	Shared Desktop Ontologies

KDE Base
 - libs
	kdelibs
	knotificationitem-experimental
 - release
	runtime
	dolphin
	konqueror
	konsole
	kwrite
 - review
	device-automounter
 - playground
	freespacenotifier
	kfingerprint

KDE Workspace
 - libs
	libkworkspace ?
 - release
	plasma
	kwin
	krunner
	kmenuedit
 - review
	some plasmoids?
 - playground
	dataengines, plasma applets
	etc.

KDE Educational
 - libs
	libkdeedu
 - release
	kalgebra
	kalzium
	kgeography
 - review
	?
 - playground
	kard
	kverbos

KDE Multimedia
 - libs
	libkcddb
	libkdemultimedia
 - release
	amarok
	dragonplayer
	juk
	kmix
	kmplayer
	kplayer
 - review
 - playground
	
KDE Network
 - libs
	libbtcore
 - release
	kget
	kopete
	krdc
	ktorrent
	konversation
 - review
 - playground
	kbluetooth
	rekonq


Q: Does the build order imply a dependency?
A: No. It implies that a dependency could happen, not that it is mandated. 
However, the reverse of the order implies an absence of dependency.

For example, Amarok could depend on libkdemultimedia if it wanted to. But it 
cannot depend on libbtcore or libkdeedu.

Q: What can my app depend on?
A: Libs inside your category, KDE Base/Libs, KDE Support. That's all.

Q: Can my app depend on another app in the same category and stage?
A: No.

Q: What can my lib depend on?
A: In the general case, KDE Base/Libs and KDE Support. If it's a KDE Base 
library, then it's a good question.

Q: What are the flaws in this design?
A: Points not addressed:
 - most libraries depend on Qt, but if Qt is in KDE Support, then there's an 
order problem
 - it's impossible to have addons/plugins to apps
 - it's impossible to have libraries depend on other libraries
And other stuff I've missed.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100127/15c51f95/attachment.sig