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
Sebastian Vahl wrote:
In last weeks KDE-SIG meeting I proposed a split of the existing KDE packages into smaller subpackages.
But be aware that both Than Ngo and me are very much against the idea.
= Metadata =
[snip]
- modularized KDE (484K):
96K primary.sqlite.bz2
- non-modularized KDE (368K):
44K primary.sqlite.bz2
This is the file everyone will have to download at every single update (even non-KDE users). It has more than doubled in size! (And it is only the factor which can be used here, not the absolute size, as only 5 modules were split in this test. Splitting all the modules will probably lead to at least 200 KB of primary.sqlite.bz2.)
Kevin Kofler
Kevin Kofler wrote:
proposed a split of the existing KDE packages into smaller subpackages.
I think this would be a lot more work for packagers and for users, as one would have to build and select each and every app separately. As it is, in kde3, we had about a dozen packages to download, now, in kde4.3.3, it is about seventy (more, if you install devel packages).
I have a notebook computer with a 40G hard drive, but I have no problem installing kde properly. The only package I deselect is kdeedu (because it's basically for kids).
On 11/16/2009 10:48 AM, 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.
Hi,
I have a Desktop machine, a Netbook (with hard disk) and one Virtual machine all running Fedora 11 my install process is:
- make a custom install in the netbook, - review all group packages and select and deselect based in the following criteria - leave all kde options selected , and select some more which I need - review the command line and graphical packages and deselect the ones which I don't need or and select some which I wll need
reinstall the netbook via the kickstart created in the above procedure, tuning ( addind or substracting packages names) the kickstart file and reinstall again until the list of packages in the kickstart is created with the only ones which I selected to install
and after that reinstall the desktop and the VM from it. ok I change the hostname and the size partitions but the list of packages is 98% equal for the three machines.
So based in the above i prefer to install kde apps, and others which
if the packages are splitted, maybe some apps will not selected to install by default, so I in that situation I will select each one manually so in my use case will be more complex.
btw my /usr partitions are filled to 4.2G from a size of 12G but I don't have space constrains in my machines
or maybe "meta packages" ( I don't if that is the correct name) will be created when the packages will be splitted, because when I tried to install koffice 2 from kde unstable I tried
sudo yum install long list rpm packages of koffice2 and the process marked some as deprecated,
in the list I saw a koffice-suite rpm package so I execute a: sudo yum install koffice-suite and it took care of install all rpms belonging to koffice2
Gabriel
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:
- 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
2009/11/16 Eli Wapniarski eli@orbsky.homelinux.org:
My particular preference... Whatever is simpler for developers and users.
This K.I.S.S. principle works best.
+1
Looking at the kdegames.spec makes me say no thanks. I guess it might be nice to be able to cherry pick one game over the other. But this isn't simple. A lot more work for developers to satisfy a handful users. Sorry.
On Mon, 2009-11-16 at 21:57 +0200, Eli Wapniarski wrote:
My particular preference... Whatever is simpler for developers and users.
This K.I.S.S. principle works best.
Eli
Fully agree. Beyond the issue of the far bigger meta-data, having to manually select large number of applications will be tiresome for most power-users and a huge-entry-barrier for new-comers.
In the end, if your machine cannot handle the added 100-200MB created by less needed applications, you're most likely should be using XFCE/IceWM and not KDE...
- Gilboa
On 11/17/2009 03:35 AM, Gilboa Davara wrote:
On Mon, 2009-11-16 at 21:57 +0200, Eli Wapniarski wrote:
My particular preference... Whatever is simpler for developers and users.
This K.I.S.S. principle works best.
Eli
Fully agree. Beyond the issue of the far bigger meta-data, having to manually select large number of applications will be tiresome for most power-users and a huge-entry-barrier for new-comers.
In the end, if your machine cannot handle the added 100-200MB created by less needed applications, you're most likely should be using XFCE/IceWM and not KDE...
Agreed. I like the way things are now.
- Gilboa
fedora-kde mailing list fedora-kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-kde New to KDE4? - get help from http://userbase.kde.org
On Tue, Nov 17, 2009 at 2:48 AM, Sebastian Vahl wrote:
So the floor is now open for all feedback, opinions, enhancements, proposals and rejections. :)
As end user, and someone who doesn't always use KDE -- it'd be quite useful. However it's not me that has to do the extra work.
Also, I'd assume the modularization will come naturally as/if KDE moves over to git?
On 11/17/2009 04:30 AM, Eric Springer wrote:
As end user, and someone who doesn't always use KDE -- it'd be quite useful. However it's not me that has to do the extra work.
But this could also lead to confusions from the users part who'd have to install lot of separate packages to complete a functionality. I remember a friend of mine installing qt-devel and finding no documentation. It was a surprise for him to learn that qt-doc was a separate package.
regards,
Syam
On Tue, Nov 17, 2009 at 11:33 AM, Sonic get.sonic@gmail.com wrote:
But this could also lead to confusions from the users part who'd have to install lot of separate packages to complete a functionality.
I was more thinking along the lines of separate applications, like installing kolourpaint4 on a gnome system is quite desirable, but you don't want to get the whole kdegraphics. Or in my case, I only want one (ksudoku) of the couple dozen games. And the only kdedu program I want is parley.
I like the way amarok and marble works. One app per package.
I remember a friend of mine installing qt-devel and finding no documentation. It was a surprise for him to learn that qt-doc was a separate package.
I had the same surprise too, but I'm glad I don't need to download a 100M docs to just build some stuff.
On 11/16/2009 09:48 AM, 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.
I'm opposed to do doing it in general. If there are specific targets, issues, perhaps doing just enough to satisfy them would be useful.