kdelibs (tier1) splitting package/repository granularity

[Kevin Ottens]

On Thursday 10 May 2012 23:00:16 Alexander Neundorf wrote:
> On Thursday 10 May 2012, Kevin Ottens wrote:
> > On Wednesday 9 May 2012 21:38:55 Alexander Neundorf wrote:
> > > I understand correctly that tier1 libs do not have any dependencies
> > > between each other, right ?
> > 
> > Correct.
> > 
> > > Do we plan to put each of those into a separate repository and release
> > > as
> > > a separate package ?
> > 
> > Correct. Still some work needed before we get there though, we're waiting
> > for the last possible moment to do the splitting.
> 
> Hmm, not sure I really want to say this, but...

Then don't? (always find this kind of sentence weird, sorry, couldn't resist) 
:-)

> I'm not sure it is necessary and brings real benefits to release all those
> small libraries spearately.
> 
> The situation with the tier1 libs is very different than with KDE4 kdelibs:
> no dependencies between each other,

Correct.

> no runtime dependencies.

Not correct. We'll have tier1 with runtime dependencies at some point. We sort 
out runtime and link time dependencies on two different axis. The "tiers" form 
the link time dependencies axis.

> Why not put all tier1 libraries into one repository and release them as one
> package ?

Well, that's *today* situation. We know how it works really, introduce a lib 
and it'll likely grow overtime. Put a set of libs in a common repo, and it'll 
be veeery tempting to sneak a dep here or there. Can't harm right? :-)

> Keep tier2 and tier3 libraries, or those which introduce different runtime
> dependencies, or those which are "big", separate.

Define big? :-)
Predict what will become big tomorrow?

> qxt does this too, and it's no problem for 3rd party users.

Well, the whole of libqxt is under 120 classes, so clearly a different scale 
than kdelibs, and already smaller than our likely incomplete current tier1. 
Also I'd be curious to know where the "no problem for 3rd party users" claim 
comes from. AFAIK it's about as successful as kdelibs for 3rd parties... that 
is: not used much.

For sure I never encountered any use of qxt in my job. QextSerialPort? Quite a 
few times already, and this one has two public classes. Doesn't make me cringe 
really.

> Having the tier1 libs in one repository would at least make maintaining the
> buildsystem easier (simply less work),

Yes, I see the incentive there.

> and it may make building the whole
> thing a bit more convenient, since you have less packages to build.
> For kdelibs developers it would be probably also a bit more convenient.

Well, they'd have to handle the tier2 and tier3 repos anyway... so back to 
square one.

> Of course each of the libs can be switched on and off separately...
> 
> So, what are the real benefits of e.g. releasing the 6-file library
> kdbusaddons as a separate package ?

Well, the points I mentionned above, and on top of that:
 * Tier positioning of a repo becomes "just" a label, so no weird 
merging/splitting repo operations if the situation of a lib has to change;
 * Consistency in the way we deal with the frameworks accross the whole 
offering ("aaah you wanted kdbusaddons this time? well contrary to the other 
ones you worked on, it is in a special repo with other tier1").

Hope that clarifies a bit.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120511/4db32425/attachment.sig>