Modular Kernel Packaging for Cloud

[Reindl Harald]

Am 06.03.2014 16:00, schrieb drago01:
> On Thu, Mar 6, 2014 at 12:38 AM, Sandro "red" Mathys
> <red at fedoraproject.org> wrote:
>> On Thu, Mar 6, 2014 at 1:45 AM, Kevin Fenzi <kevin at scrye.com> wrote:
>>> On Wed, 05 Mar 2014 17:37:42 +0100
>>> Reindl Harald <h.reindl at thelounge.net> wrote:
>>>> in general you need to multiply the wasted space for each instance
>>
>> Exactly, you usually have hundreds or even thousands of instances
>> running. Sure, "every MB counts" isn't to be taken literal here, maybe
>> I should rather have said "every 10 MB count".
> 
> I suggested this once before and got no real answer but if you are so
> disk space constrained wouldn't file system compression
> do what you want instead of trying to micoroptimize every package?

since there is no transparent compression for the rootfs and
even after btrfs get stable you shouldn't just convert
existing installations from 2008 that's no option

reducing package sizes would affect 5 years old setups too
but as said - i see more sane potential to split the glibc
locales out to sub packages which are as big as the kernel
then risk breaking updates because needed modules are in
a now extra package

another thing would be split docs and manpages in general
in subpackages - only god knows if and when DNF supports
"tsflags=nodocs" which is driven by a yum plugin

another thing would be to split database support of libraries
in subpackages -> dbmail pulls libzdb which pulls mysql, postgresql..
and take a deeper look in circular dependencies at all, i had
several "nice to have" things on my servers and removing
some of them ended in a freed dependency chain uninstalling
400 MB on each machine and even more on some - over the years
i reduced my rootfs-usage down to 40-50% that way

some of these expensive dependencies i solved by maintain
such packages at my own and disable postgresql support
completly - but that's only a sane way in a defined
environment

so again: there are *many* places to gain more than
with the kernel itself and especially in case of C
software yum pulls such subpackages in most cases by
implicit dependencies