Separating everything ?

Treeve Jelbert treeve at scarlet.be
Wed Feb 6 19:12:49 UTC 2013


On Wed, 6 Feb 2013 19:57:09 +0100, Alexander Neundorf wrote:
> Hi,
>
> at Kevin's talk about KDE frameworks at FOSDEM last weekend, one guy
> from the
> audience asked why he should not use all KDE libs if he decides to 
> use one
> already...
>
> This got me thinking.
> Obviously, dragging in everything is what we want to avoid.
> Making kdelibs modular should also make building the libs easier. I 
> mean, if
> I'm a developer under Windows and want to use only karchive, I "only"
> have to
> make sure zlib, bzip and lzma can be found, and I'm fine to go.
> Orders of magnitude better than before, where I would have had to 
> make sure
> enough from kdesupport can be found so I can start building kdelibs,
> including
> strigi, nepomuk, etc.
>
> Still... the tier1 libraries will not have any interdependencies.
> Especially the tier1 functional libs.
> And they are partly really tiny.
>
> If they don't have any interdependencies, it is trivial to add a
> cmake switch
> for each of them, so if I want only karchive, I simply disable all 
> others.
> Qxt does it similar IIRC.
>
> Kevin actually suggested that breaking it into too many very small 
> packages
> would indeed be quite some work for packagers.
>
> So, what do I suggest ?
> Let's put all tier1 function libs into one repository and package,
> making it a
> bit easier for the packagers (and also for developers, who have to 
> deal with
> maybe 10 to 20 repositories less).
>

As a packager, I would be in favour of separate repos for tier1, tier2, 
...
Why not create tier{1,2} repos immediately, if they can build 
standalone?




> Or, just do that for tier1 functional libs, this is more narrow in 
> scope.
>
> I mean, what real benefit do we get from having a separate package 
> for every
> tiny library ?
>
> Comments ?
>
> Alex
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel



More information about the Kde-frameworks-devel mailing list