[Kde-scm-interest] Package splitting
thiago at kde.org
Wed Jan 27 22:46:52 CET 2010
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
Shared Desktop Ontologies
dataengines, plasma applets
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?
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
- 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
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
More information about the Kde-scm-interest