Am 06.03.2014 16:00, schrieb drago01: > On Thu, Mar 6, 2014 at 12:38 AM, Sandro "red" Mathys > <red@xxxxxxxxxxxxxxxxx> wrote: >> On Thu, Mar 6, 2014 at 1:45 AM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: >>> On Wed, 05 Mar 2014 17:37:42 +0100 >>> Reindl Harald <h.reindl@xxxxxxxxxxxxx> 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
_______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
