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.
