Launchpad Entry: foundations-m-spring-cleaning
Created: 3 May 2010
Packages affected: many
Clean up cruft in Maverick.
Not particularly user-visible; no release note required.
Right after an LTS release is a good time for an aggressive cleanup of things we don't need or that should be extensively refactored.
We investigated several sources of cruft, and came up with a number of space savings.
lucid-duplicated-packages had several work items that had to be dropped or postponed due to lack of time in the 10.04 LTS cycle; we will review and complete them as appropriate.
The new dpkg in Maverick supports data.tar.xz compression, although Launchpad does not yet do so. Once archive support is available, we should convert existing packages using -Zlzma to -Zxz. We can drop lzma from the base system right away, though, since xz-utils can unpack lzma-compressed packages.
The transition from libjpeg6b to libjpeg8 is a large one, but we should get started sooner rather than later. (Note that libjpeg8 is substantially easier to cross-compile.)
insserv and sysv-rc should go away once Upstart handles traditional init scripts itself. We will not consider that further as part of this specification; Upstart developers will get rid of them as appropriate.
It should be possible to eliminate klibc from the initramfs, and this has been discussed recently on debian-devel. Some binaries are provided by klibc at the moment:
cpio - unused?
dd - could be provided by busybox
dmesg - could be provided by busybox
fstype - switch to blkid?
halt - could be provided by busybox
insmod - could be provided by busybox
ipconfig - TBD
losetup - could be provided by busybox
nfsmount - switch to busybox mount?
pivot_root - could be provided by busybox, but unused?
poweroff - could be provided by busybox
reboot - could be provided by busybox
resume - TBD
run-init - TBD
(We discussed applying library reduction to the initramfs; this is at best a dark grey art, and is not urgent for our purposes here.)
We could substantially reduce the size of the minimal seed by installing tasksel and aptitude dynamically, so that we don't end up with them on live-installed systems. We will still need to keep tasksel in the server seed.
Is gnupg's recommendation of libldap-2.4-2 correct? It seems perhaps not, so we will check this and downgrade it to a suggestion if appropriate.
ftp duplicates the more capable lftp, installed as part of desktop. However, lftp is much larger. This requires discussion on ubuntu-devel.
Is command-not-found appropriate for standard? This requires discussion on ubuntu-devel.
We will investigate whether libdns can load libgeoip dynamically; geoip-database is quite large and may not be necessary in all situations.
Is iputils-arping really standard? This requires discussion on ubuntu-devel.
iputils-tracepath and mtr-tiny seem to be somewhat duplicated; iputils-tracepath offers IPv6 while mtr-tiny offers a full-screen interface. We will investigate this.
We will look into whether language-selector-common is needed in standard, or whether it can usefully be installed dynamically.
apparmor-utils depends transitively on libwww-perl, which seems of marginal benefit at best. We will investigate this dependency chain.
In general, we should keep an eye out for anything related to e-mail in standard, since no MTA is included.
bogofilter is mainly useful for evolution, which isn't in desktop-common. We will remove this and allow it to be pulled in by dependencies.
cdparanoia seems marginal these days; most people will be using GUI equivalents now. We will very likely drop this.
dvd+rw-tools and wodim should not need to be explicitly seeded, since most desktops will pull them in anyway.
acpi-support depends on finger and actually uses it! The answer is probably to finish removing acpi-support, but if that isn't possible then we will excise its dependency on finger.
It might be better to maintain the list of printing packages somewhere other than the seeds; we will discuss this with Till Kamppeter, who maintains our printing subsystem.
libgl1-mesa-* were explicitly seeded as Germinate workarounds, but may no longer be needed. We will investigate this.
It is a wart that libthai has to be installed everywhere for libpango. We will investigate whether it can be loaded dynamically.
lm-sensors is pulled in via libhpmud -> libsnmp -> libsensors; perhaps some of this can be optional?
foo2zjs depends on Tcl/Tk; we will make enquiries regarding whether this be ported to a widget set we use elsewhere.
Other points arising
We will investigate replacing bzip2 with its parallel replacement pbzip2 (550507). Note, though, that it delivers a distinct command name so would be tedious to replace in many places.
For many discussions like this, a repository of unpacked source and possibly a specialised search engine would be valuable. The source for the short-lived source.debian.net is available, and we will investigate whether we can run this for Ubuntu, possibly in combination with a Lintian laboratory.
It would be nice if plymouth-x11 could be separated into plymouth-gtk and plymouth-qt. This is not recorded as a work item for this specification because a Qt port of Plymouth would be substantial work, but it would help to reduce Kubuntu's footprint if it could be done.