TODO List for Etch
Hi all - this might become a bit of a TODO list for Etch.
Don't list issues with single packages here - we have the bug tracking system for this! http://bugs.debian.org
Don't list proposals here on how the Etch release should be managed. There is ["ReleaseProposals"] for this.
For all issues, please try to provide links to mailing list discussions etc. - while the Wiki is good for keeping track of issues up to some point, it is not a good discussion medium imho. So, if you list controversial issues here, DON'T discuss these things here and don't just remove them - add links to relevant parts of the mailing list archives.
Here is a summary of the discussions in the "and now to something completly different... etch!" and "TODO for etch ?" threads I found in the debian-devel mailing list archive:
[http://lists.debian.org/debian-devel/2005/06/msg00979.html wiki:?ABI Complete transition to gcc 3.4/4]
[http://lists.debian.org/debian-devel/2005/06/msg00979.html Resolve FDL issue]
[http://lists.debian.org/debian-devel/2005/06/msg00979.html Get Xorg into the archive]
[http://lists.debian.org/debian-devel/2005/06/msg00979.html Get new KDE version into the archive]
[http://lists.debian.org/debian-devel/2005/06/msg00979.html Support multiarch], whatever that is;-)
[http://lists.debian.org/debian-devel/2005/06/msg00980.html Get ["OOo2"] into the archive]
[http://lists.debian.org/debian-devel/2005/06/msg00982.html New apt-get]
[http://lists.debian.org/debian-devel/2005/06/msg00982.html Add ["AMD64"] port] officially
[http://lists.debian.org/debian-devel/2005/06/msg00982.html The "scc" archive split] to lighten load on mirrors
[http://lists.debian.org/debian-devel/2005/06/msg00999.html Improve hardware detection] and [http://lists.debian.org/debian-devel/2005/06/msg00462.html detect Hardware changes] system detects after a reboot when a new SVGA card, new Ethernet card, etc. has been installed and prompts for new confguration. [http://lists.debian.org/debian-devel/2005/06/msg00480.html must be easy to remove]
[http://lists.debian.org/debian-devel/2005/06/msg00999.html Replace default syslog-daemon] to one capable to storing severity/facility in the log file.
[http://lists.debian.org/debian-devel/2005/06/msg00999.html Change boot system], to one capable of handling dependencies and parallel invocation, to speed up the boot process. [http://lists.debian.org/debian-devel/2005/06/msg00462.html see Solaris 10] or http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/)
[http://lists.debian.org/debian-devel/2005/06/msg01011.html Implement multi level configuration] and some other unpopular ones (needed for cdds)
[http://lists.debian.org/debian-devel/2005/06/msg01011.html Implement automatic reconfiguration of packages] and change policy to allow for that (needed for cdds)
[http://lists.debian.org/debian-devel/2005/06/msg01011.html Allow 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)
[http://lists.debian.org/debian-devel/2005/06/msg01028.html More finely grain task selection], [http://lists.debian.org/debian-devel/2005/06/msg00462.html Automatically detect] user needs. Automate task selection?
[http://lists.debian.org/debian-devel/2005/06/msg01028.html 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 [http://lists.debian.org/debian-devel/2005/06/msg01031.html already done]).
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Fix all bugs in base] (Personal note: packages in base packages older than a year should either be closed or handled properly, i.e. fixed)
- Base system should be upgraded to latest upstream (forward patches!) this includes PAM, modutils...
[http://lists.debian.org/debian-devel/2005/06/msg00462.html 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 [http://lists.debian.org/debian-devel/2005/06/msg00480.html make this unnecessary]), a [ virtual firewall package] might be a good idea to stop admins from installing several (conflicting) firewall rulesets.
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Reduce standard installation] (no gcc or development tools!, see #301138 or #301273)
[http://lists.debian.org/debian-devel/2005/06/msg00462.html package signature checks] (apt-secure, currently on experimental)
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Add systematic buffer overflow protection]: ?ExecShield or PaX in stock kernel
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Support Mandatory Access Control]: ["SELinux"] support (RSBAC?)
[http://lists.debian.org/debian-devel/2005/06/msg00462.html wiki:?SPP Add option to recompile the distro with] (apt-build?). New i386-spp architecture?
[http://lists.debian.org/debian-devel/2005/06/msg00462.html 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?
[http://lists.debian.org/debian-devel/2005/06/msg00462.html ["MD5"] / SHA-1 listing of files in ftp sites] (useful for forensics analysis see #303961)
[http://lists.debian.org/debian-devel/2005/06/msg00729.html Harmonize, internationalize output of initscripts] (verbose as default and/or simple as ["ok"]/["notok"] (ok, this is really needed only on a desktop, in production you are supposed to read and debug error messages yourself))
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Support "status" method in initscripts] (#291148)
[http://lists.debian.org/debian-devel/2005/06/msg00481.html 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...)
[http://lists.debian.org/debian-devel/2005/06/msg00701.html Do not start daemons on installation]. Starting daemons on installation causes trouble in chroot setups. Objection: Starting daemons is [http://lists.debian.org/debian-devel/2005/06/msg00718.html a feature] of debian which should not get removed and [http://lists.debian.org/debian-devel/2005/06/msg00718.html policy-rc.d] already allows an admin to override the default behaviour.
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Implement "control" mode in initscripts]: 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) [http://lists.debian.org/debian-devel/2005/06/msg00708.html same for modules to load]
[http://lists.debian.org/debian-devel/2005/06/msg01028.html Support debtags in the package system], since I often spend time searching the right application by google and then checking it it's already packaged
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Implement better package search mechanism] allowing free text search in package management interfaces: "I want a program that does X" [http://lists.debian.org/debian-devel/2005/06/msg00843.html apt-cache is not enough]
[http://lists.debian.org/debian-devel/2005/06/msg00462.html inetd begone!]: Replace with xinetd or [http://lists.debian.org/debian-devel/2005/06/msg00464.html saner inetd], or [http://lists.debian.org/debian-devel/2005/06/msg00620.html remove it altogether], [http://lists.debian.org/debian-devel/2005/06/msg00464.html Allow for easy switching] of inetd (depends on a better update-inetd script).
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Checksecurity] > live up to its name and merge changes from other distros and ["BSDs"]
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Security / Update managements of multiple servers] rom 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
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Provide better backup management] -> upgrade rollback? [http://lists.debian.org/debian-devel/2005/06/msg00551.html use backup tools], this would require [http://lists.debian.org/debian-devel/2005/06/msg00552.html downgrades] which are not supported.
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Separate runlevels] as defined in LSB. [http://lists.debian.org/debian-devel/2005/06/msg00551.html current way is a feature.]
[http://lists.debian.org/debian-devel/2005/06/msg00462.html 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)
[http://lists.debian.org/debian-devel/2005/06/msg00462.html 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 [http://beaglewiki.org/Main_Page beagle] or [http://www.kde-apps.org/content/show.php?content=22135 kat]/... can be used for this?
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Improve the Debian Reference] to the level of what RedHat or ["SuSE"] already provide
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Internationalize documentaion] in CD-["ROMs"], better track of out-of-date translations
[http://lists.debian.org/debian-devel/2005/06/msg00462.html 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)
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Remove all out of date dummy packages]. See #308711 and other bugs!
[http://lists.debian.org/debian-devel/2005/06/msg00462.html Track bugs associated with testing release better] (not manually!)
[http://lists.debian.org/debian-devel/2005/06/msg00464.html Drop support for 2.2 and 2.4 kernels], even though 2.6 does still contain some [http://lists.debian.org/debian-devel/2005/06/msg00553.html regressions] at this point (which hopefully will [http://lists.debian.org/debian-devel/2005/06/msg00897.html not be an issue] anymore when etch is released). [http://lists.debian.org/debian-devel/2005/06/msg01035.html some features] require a 2.6 kernel and many packages are easier to maintain if the existens of sysfs can be assumed. d-i would be happy about [http://lists.debian.org/debian-devel/2005/06/msg00876.html having this decission soon]. [http://lists.debian.org/debian-devel/2005/06/msg00884.html 2.6 kernels will not fit onto a floppy] though, so this will break floppy-based installs ([http://lists.debian.org/debian-devel/2005/06/msg01053.html proposed workarounds], or [http://lists.debian.org/debian-devel/2005/06/msg01044.html replace mkinitrd] which is [http://lists.debian.org/debian-devel/2005/06/msg01046.html not used by d-i])
[http://lists.debian.org/debian-devel/2005/06/msg00480.html Add laptop task]. [http://lists.debian.org/debian-devel/2005/06/msg00544.html Look at the laptop-detect package] in ubuntu.
[http://lists.debian.org/debian-devel/2005/06/msg00496.html Make it a lot easier to install at medium priority]. IMO there is a real use for medium priority:
- experienced users now often choose expert and get confused by some of the informational dialogs (especially the "unavailable drivers" one)
- for users installing for the first time the "no dhcp" boot option and such are not really obvious, medium priority can be used to offer useful freedom in a structured way keeping expert for difficult hardware
[http://lists.debian.org/debian-devel/2005/06/msg00499.html Add networking equivalent of the pmount group]. People in these groups would be allowed to edit the network files (in particular /etc/network/interfaces) and bring interfaces up and down. Obviously on servers and corporate desktops this group would be empty or contain only system admins, but on a lptop 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. [http://lists.debian.org/debian-devel/2005/06/msg00516.html wiki:NetworkManager] is mentioned here (ubuntu is incorporating that already into breezy), a KDE frontend to that seems [http://lists.debian.org/debian-devel/2005/06/msg00612.html possible].
[http://lists.debian.org/debian-devel/2005/06/msg00501.html Reorganize packages] that have been postponed over several releases; e.g., #100332: "tetex-bin: please move xdvi to its own package"
[http://lists.debian.org/debian-devel/2005/06/msg00512.html Switch to mingetty]. Is there any reason to use getty by default? [http://lists.debian.org/debian-devel/2005/06/msg01061.html reasons to switch]
[http://lists.debian.org/debian-devel/2005/06/msg00585.html Provide better unicode coverage in fonts] so that KDE/Gnome can display the http://www.wikipedia.org titlepage with all characters.
[http://lists.debian.org/debian-devel/2005/06/msg00627.html Use UTF-8 locales by default]. Do not break [http://lists.debian.org/debian-devel/2005/06/msg00630.html compatibility] while doing this and do not change settings on upgrade.
[http://lists.debian.org/debian-devel/2005/06/msg01025.html 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)
[wiki:?["IPv6"] http://lists.debian.org/debian-devel/2005/06/msg01025.html Make packages in etch handle] There are still a bunch of packages which are not ready.
[http://lists.debian.org/debian-devel/2005/06/msg01025.html 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.
- What about ubuntu? Will Debian move closer to ubuntu now that sarge is out? They have done lots of improvements that will be valuable for debian users I think. Ubuntu keeps feeding debian updates into their release, will debian now incorporate some of these ubuntu-changes? Are there plans on improving the cooperation of the two distributions?
PS: See http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals for a list of new features in the next ubuntu and how far they got with implementing them.
PPS: I am both a ubuntu and debian user and not directly involved with either of the projects.
slang (used in base and debian-installer) should transition from 1.4.9 to 2.0+ ; See http://wiki.debian.net/?EtchSlang2upgrade for details. Transition testing possible via the http://people.debian.org/~mckinstry/debian/experimental repository.