Unwanted RPM dependencies
David Timms
dtimms at iinet.net.au
Mon Jun 4 12:59:16 UTC 2007
Bernardo Innocenti wrote:
> (Cc'ing all the relevant package maintainers. sorry if
> I got someone else by mistake)
>
>
> We could get rid of a few packages on the OLPC in a cleaner
> way if we could loosen dependencies a little.
>
> Some random things I noticed:
>
> - cracklib has a hard dependency on pam. Is there a way
> we could make it optional?
>
> - mkinitrd depends on lvm2 and dmraid. Both could easily
> be made optional.
>
> - hal depends on cryptsetup-luks (containing bulky 1.2MB
> static binary in /sbin)
>
> - libuser and GConf2-dbus bring in openldap, which brings
> in cyrus-sasl
>
> Using pristine Fedora packages in OLPC is an advantage for
> support and upgrades. Also, reducing the minimum install
> generally benefits other Fedora spins for other small
> systems.
Since I also play with older systems with small disks I was going
through a minimal install {text mode only} and found that about 15
packages get installed because of grub dependencies: a tree (bottom is
what is required by others higher up: {text mode is good for reading}
grub
|
redhat-artwork <--> fedora-logos
| |
gtk2-engines |
| |
____gtk2__________ |
/| \ \ \ |
/ | \ cups-libs hicolor-icon-theme
/ | \ | \----------\
atk pango libtiff {pango} gnutls {gtk2}
| \ \ \ |
libthai cairo libjpeg libXft libXcursor libXrandr libX..
/ | \ / | / |
{libXrender} libpng fontconfig libXrender libXext
\ /
libX11
At which point it's getting boring ;) and still involves:
libXinerama libXau libXdmcp libXext libXi libXfixes
I think what the dependency on fedora-logos would be for the boot logo.
My idea would be to separately package/sub package fedora-logos-boot or
fedora-boot-logos {which provides logos-boot}. This would just have the
logo in it, and grub rpm would be modified to require a virtual
dependency of logos-boot {this would make it simpler for distro
packagers to use an alternate logos-boot package}. I haven't looked at
the actual packages yet.
My second size concern comes from glibc-common, specifically the
/usr/share/locale {283 MB} ( but also and /usr/share/i18n/ 10MB)
I notice that there are dependencies listed in comps.xml for what gets
installed when a language is chosen {eg dictionary and openoffice
translations}. This could be extended to the gazillion locales supported
by glibc and fedora. The maybe most commonly installed individual
locales could be made into separate packages {guessing ! english french
german spanish portuguese ? ?}, and then continent or similar for the
rest of the locales {noting that there is often sub-locales for some
reqions} {eg african latin-american asian european} ? Installing
European would also get the more specific english/french/german loc's.
This would actually reduce install time quite a bit - of the 600+
packages that get installed in a base install, the most time seems to be
taken by the glibc-common install - and it's installing stuff that
depending on your locale you are unlikely to ever use the other 99% of them.
I did have a thought on whether there exists a tool that can log/count
file accesses on disk, and then provide reports on used v not used files
that were installed by rpm ? Such a thing could help in understanding
actual usage by applications - and hence what might be better packaging
splits. Has someone done that before ?
DaveT.
More information about the fedora-devel-list
mailing list