Small user survey: More modularized KDE packages?

[Eli Wapniarski]

My particular preference... Whatever is simpler for developers and users.

This K.I.S.S. principle works best.

Eli 

On Monday 16 November 2009 18:48:19 Sebastian Vahl wrote:
> Hi.
> 
> In last weeks KDE-SIG meeting I proposed a split of the existing KDE packages 
> into smaller subpackages. My main motivation for doing this proposal was the 
> ability to only install the packages/applications that are really wanted. My 
> small-sized netbook SSD and the KDE live images were targets for this.
> 
> With this mail I want to ask you as users of Fedora-KDE what you think about 
> this proposal. Because if you don't want a more modularized KDE in Fedora 
> (whch would also introduce some more complexity) there is no need to do this.
> 
> I prepared a wiki page with the work I've done so far. For easier discussion I 
> paste a copy of it in this mail:  
> https://fedoraproject.org/wiki/SebastianVahl/modularKDE
> 
> 
> So the floor is now open for all feedback, opinions, enhancements, proposals 
> and rejections. :)
> 
> Sebastian
> 
> 
> 
> 
> = Motivation =
> 
> My personal motivation for splitting the KDE packages into more granulated 
> packages could be differed into these steps:
> 
> 1. Possibility to only install the wanted applications on my netbook (only 16 
> GB SSD).
> 2. Some repeating requests in the german fedora forum to split the packages 
> like other distributions.
> 3. Finer package selection on the live images. 
> 
> = Pros and Cons =
> 
> == Pros ==
> 
> * Ability to only install what the user want.
> * Small runtime for special targets like netbooks possible.
> * cherry-pick the applications in a non-KDE environment. 
> 
> == Cons ==
> 
> * More overhead in metadata (difficult for unstable network connections) (see 
> #Metadata)
> * More complexity when installing and updating packages
> * More work for packagers 
> 
> = What I've done so far =
> 
> I've split the packages on a per-app basis (based on the Specs for F11). So 
> for each binary of a KDE package there is a new subpackage. The subpackages 
> are named this way: <kdepackage>-<binary> (eg. kdegraphics-okular). Where 
> necessary there is also a dependent -libs package (eg. kdegraphics-okular-
> libs). Commonly used files (such as icons) and files that (may be) used by all 
> subpackages are located in a -common subpackage (eg. kdegraphics-common). 
> Commonly used libraries are located in a common-libs subpackage (kdegraphics-
> common-libs)
> 
> The work done yet is in a very early stage. The focus was on making the 
> initial split to see how it works. The %summary and %descriptions for the new 
> subpackages needs to be added and I've also left out a proper %changelog for 
> now (just increased the %release). Also the upgrade path for packages which 
> don't have a -common-libs subpackage needs to be done.
> 
> However, if someone wants to have a look a the specs: 
> http://www.deadbabylon.de/fedora/kde-modular
> 
> = Abstract =
> 
> * <kdepackage>-<binary> contains only one application (eg. kdegraphics-okular)
> * <kdepackage>-<binary> provides <binary> (eg. kdegraphics-okular provides 
> okular)
> * <kdepackage>-<binary>-libs contains dependant libraries for multilib (eg. 
> kdegraphics-okular-libs)
> * <kdepackage>-common contains files used by all subpackages (such as icons)
> * <kdepackage>-common-libs contains libraries used by all subpackages (when 
> needed)
> * <kdepackage> is just a metapackage which requires all subpackages. (so you 
> just get the normal kdegraphics when installing kdegraphics) 
> 
> = Variations =
> 
> Splitting could also be done in different ways. Some of them would be:
> 
> * Do not split on a per-app-basis but on a "popular" basis (eg. the -extras 
> subpackages with not so popular applications like we've done in late KDE3 
> days.)
> * Leave a monolithic -libs subpackage and do not split out the application 
> libraries (eg. no kdegraphics-okular-libs) 
> 
> = Metadata =
> 
> The metadata would increase when adding more subpackages. This could be 
> difficult for unstable network connections because they had to download more 
> metadata (for each update we do). The following sizes are based on a split of 
> kdegames, kdegraphics, kdemultimedia, kdenetwork, kdepim, kdeutils.
> 
> * modularized KDE (484K): 
> 
> 168K    filelists.sqlite.bz2
> 140K    filelists.xml.gz
> 28K     other.sqlite.bz2
> 12K     other.xml.gz
> 96K     primary.sqlite.bz2
> 32K     primary.xml.gz
> 4,0K    repomd.xml
> 
> * non-modularized KDE (368K): 
> 
> 152K    filelists.sqlite.bz2
> 132K    filelists.xml.gz
> 12K     other.sqlite.bz2
> 4,0K    other.xml.gz
> 44K     primary.sqlite.bz2
> 16K     primary.xml.gz
> 4,0K    repomd.xml
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.