This is a list of things which are more or less likely to be implemented in time for the release of Etch. Please read EtchTODOListMeta for information on this list before making any changes. See also the "Bits from the release team" posts to debian-devel-announce, like the Fri, 14 Oct 2005 one, as well as the current list of architectures which are to be considered a candidate release architecture on ?CategoryEtchReleaseRecertification.
Finally, be sure to take a look at Release Critical Issues for Etch according to this definition which is maintained by the Release Team.
Contents
Proposed changes
Policy application
- Remove non-free firmware (downloadable co-processor software) from the kernel (Kernel Team)
Distribution infrastructure
Implement multi level configuration for popular services and some other unpopular ones (needed for cdds)
Implement automatic reconfiguration of packages and change policy to allow for that (needed for cdds)
Enhance apt to install special configuration packages (which pre-seed debconf or supply configuration by other means before the packages that are to be pre-configured) are installed or reconfigured (important for modularized preconfigured subsystems)
More finely grain task selection, Automatically detect user needs. Automate task selection?
MD5 / SHA-1 listing of files in ftp sites (useful for forensics analysis see 303961)
Allow dpkg to be used as an audit tool to detect changes in the system, not as a security mechanism but to detect broken stuff (includes 155799 and 34194)
Issues that affect several packages
Various library transitions, see OngoingTransitions and ?EtchSlang2upgrade (also these different posts)
Package additions, removals, replacements
Add laptop task. Look at the laptop-detect package in ubuntu.
Prune packages from release based on popularity, packages which are not used by anyone should not go in! (not enough peer review, probably not audited, bug ridden with bugs, including security making security handling a nightmare)
?Remove Ruby1.6.
Service init and management
Firewall configuration during installation: module for d-i. Currently, the system is exposed just during installation on some systems (empty root password?) (Improved d-i might make this unnecessary), a [ virtual firewall package] might be a good idea to stop admins from installing several (conflicting) firewall rulesets.
Change boot system, to one capable of handling dependencies and parallel invocation, to speed up the boot process. see Solaris 10 or http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/) Lars Wirzenius
Separate runlevels as defined in LSB. current way is a feature.
Harmonize, internationalize output of initscripts (verbose as default and/or simple as [ ok ]/[ notok ] (lsb-initscripts should bring this))
Support "zap" method in initscripts. Altough it's a solution from 'should never be needed' dept. ask yourself how many times you had to killall -9 $something! (...not that killall is the right solution for zap...)
Do not start services on installation. Starting daemons on installation causes trouble in chroot setups. Or rather, Always start services on installation. Starting services on installation makes sense. Peculiar schemes for disabling services implemented in packages should in most cases be eliminated. Appropriate ways to disable a service are: to de-install the package; to use sysv-rc-conf to change the runlevel settings; policy-rc.d. Or just do like the udev package does and detect chroot environments[?FootNote(Udev seems to "detect chroot" by checking if proc is mounted. For chroots with proc bind-mounted such check fails.)].
Implement boot in "control" mode: i.e., select which initscripts will run, this provides a way to work around hardware issues after d-i has installed the base system (personal example: 301112) same for modules to load
Replace default syslog-daemon to one capable to storing severity/facility in the log file.
Security enhancements
Add systematic buffer overflow protection: ExecShield or !PaX in stock kernel
Support Mandatory Access Control: SELinux support (RSBAC?). See ?SELinuxStatus for details on the progress.
Add option to recompile the distro with SPP (apt-build?). New i386-spp architecture?
Audit source code properly. This way we will detect stupid security bugs (/tmp/XX.?? anyone?) Recurrent things like 306893 appear all too often. Automatic source code audit ala lintian.debian.org?
Checksecurity live up to its name and merge changes from other distros and BSDs.
Security / Update managements of multiple servers from a single point. There's no single tool to do check the security status of many servers at once (like done in RedHat's Network). Use OVAL agents? See 253097
Documentation, internationalization, localization
Offer more convenient help/documentation search (dwww sucks, dhelp needs improvement) Provide a "Debian documentation center" with search functions to detect information in READMEs, html files, manuals relevant to a free-text query? Desktop search is in the works by several projects already, maybe beagle or kat/... can be used for this?
Improve the Debian Reference to the level of what RedHat or SuSE already provide
--- We need volunteer. My attempt: http://wiki.debian.org/DebianReference
Internationalize documentation in CD-ROMs, better track of out-of-date translations
Provide better unicode coverage in fonts so that KDE/Gnome can display the http://www.wikipedia.org titlepage with all characters.
Other issues (wishlist, generic, vague, etc)
- Get rid of all non-debconf questions and similar stuff. Get rid of useless debconf abuse.
Fix packages in base and packages up to priority standard so as not to use savelog. There is at least one package in base i know off which uses savelog to rotate logfiles. Using logrotate is a more save way, as it gives the user the possibility to configure more easyly when logfiles are rotated. I would like to see 5(j) of etch release-policy adjusted or best, to say, all packages must use logrotate.
Document tcpwrappers usage in all packages A lot of programms use tcpwrapper which I appreciate a lot. However, it is quite often not too easy to find out what to write in hosts.allow to allow access to exactly that program. Frankly speaking, having that information always in the manpage seems a good idea to me. (i would like to see that as recommondation for packages in etch)
Reorganize packages that have been postponed over several releases; e.g., 100332: "tetex-bin: please move xdvi to its own package"
Review all package descriptions. See PackagesDescriptionsReview
- Base system should be upgraded to latest upstream (forward patches!) this includes cron, PAM, modutils...
- Replace Exim by Postfix as default MTA. Postfix seems to be the default in Linux land, and is arguably easier to use.
Add support in DebianInstaller to recognize SATA software raids, dm-raid is already in debian sid and can be integrated and added to partman, no urgent need to support creations or managements of raids, since it can be done by the BIOS, just show up the device /dev/mapper/<dm-raid_name>.
Add support in DebianInstaller to install on EVMS volumes, evms and init{rd,ramfs} is already in debian sarge and can be integrated in partman embedding evmsn (ncurses) or evmsgui (to be recompiled with gtk-dfb).
- move to LSB 3.0 compatibility; discuss with Debian LSB team.
Done
Track bugs associated with testing release better (not manually!)
Improve menu system: I'd like to have the possibilty to hide some programs from the users menu, or from groups of users. (Appearently this is already done).
Get Xorg into the archive (David Nusinow and the X Strike Force)
Improve hotplug - make it faster and less painful; deal with excluded modules in a sane way (udev has replaced all hotplug scripts and other weirdness, blacklisting is now supported in modprobe).
Improve or remove hotplug in its present shape (hotplug is gone with recent udev)
Use UTF-8 locales by default (DebianInstaller now installs a system with UTF-8 as the default, see also this posting).
Support debtags in the package system, since I often spend time searching the right application by google and then checking if it's already packaged
Implement better package search mechanism allowing free text search in package management interfaces: "I want a program that does X" apt-cache is not enough (see the preceeding point about debtags)
Implement the "scc" archive split to lighten load on mirrors (this seem to be implemented 2006-04-15?)
Drop support for 2.2 and 2.4 kernels. Decision to do so by the kernel team can be found here. (Note: even though 2.6 does still contain some regressions at this point which hopefully will not be an issue anymore when etch is released. some features require a 2.6 kernel and many packages are easier to maintain if the existence of sysfs can be assumed. d-i would be happy about having this decision soon. 2.6 kernels will not fit onto a floppy though, so this will break floppy-based installs (proposed workarounds, or replace mkinitrd which is not used by d-i). This does not imply dropping support for OSS in favour of ALSA. OSS is still needed for GNU/?kFreeBSD, for example.)
inetd begone!: Replace with xinetd or saner inetd, or remove it altogether, Allow for easy switching of inetd (depends on a better update-inetd script) (saner inetd, openbsd-inetd is now in, the dependency from netbase on an inetd server wil be dropped after Etch is released).
Add pifupdown -- networking equivalent of pmount. Users in a special group would be allowed to bring interfaces up and down and to configure them. Obviously on servers and corporate desktops this group would be empty or contain only system admins, but on a laptop you have to be able to fit into the network you are presented with and you do not want joe-user to be switching to root all the time just in order to do these functions. wiki:Self:NetworkManager is promising (ubuntu is incorporating that already into breezy); a KDE frontend to that seems possible. (Fixed with the inclusion of NetworkManager)
Improve hardware detection and detect Hardware changes system detects after a reboot when a new SVGA card, new Ethernet card, etc. has been installed and prompts for new configuration. must be easy to remove (a default desktop system now comes with a recent 2.6.X kernel, HAL and udev which gives automated hardware mgmt)
Reduce standard installation (no gcc or development tools!, see 301138 or 301273 )