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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
