On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote: > Release Goals > ------------- > As a first step towards establishing release goals for wheezy, we will > be reviewing each of the goals which we had for squeeze [RDO:SGoals] to > see which have been achieved and which may no longer be relevant for > other reasons. Here's a list of things I'd like to see in squeeze, though I probably won't have time to push them all myself: • C.UTF-8 provided by default, to provide a guaranteed present standard C locale (#609306). Looks like this is now in eglibc (2.13-0exp3) in experimental, so the main remaining task is to convert existing packages (lintian etc.) which currently generate their own locales and/or use other locales to use C.UTF-8. Thanks to Aurelien Jarno for pushing this. As a followup, I would like to get the UTF-8 codeset and collation hardcoded in libc6 directly and sharable by all UTF-8 locales to reduce startup time and needless duplication (due to using a separate codeset facet for each locale loaded). This would allow the subsequent creation of a real "C" locale using a UTF-8 codeset. Needs some digging into the eglibc locale code though. • /run (as being currently discussed) Easy enough to add the top-level directory. We do however need to cope with handling upgrades, compatibility bind mounts and/or symlinks etc. I've been working on an initscripts patch to handle this, but it will need wider discussion and testing. Given the historical usage of /var/run and /var/lock, we will need to keep compatibility links in place for the foreseable future, if not indefinitely, plus compatibility /lib/init/rw link to allow for squeeze upgrades. • dpkg-buildpackage support for build-arch and build-indep by default AFAICT requires a mechanism to autodetect the presence of the targets in the rules file to allow their use if present, falling back to the build target if absent. This is a long standing deficiency in our toolchain, which is preventing correct support for Build-Depends-Indep/ Build-Conflicts-Indep in autobuilding, since the build target may or may not require Build-Depends-Indep when doing binary-only builds (and vice versa). Having the correct separation will permit sane and reliable build dependency installation. This will become more of an issue with arch-all autobuilding. This is something we've wanted for years, but which has continually been stalled by issues doing the migration. We've got support for build-arch and build-indep in cdbs and dh, which makes over 50% of the archive support them today. Developers can add the targets today, and add build: build-arch build-indep to have their package build with both current and future versions of the toolchain, with the appropriate bits being doing in each rule. I've proposed a change to Policy to change this from "may be provided" to "must" (#604397). Some previous proposals have called for this to be enabled if >= a certain Standards-Version is supported, or a flag in Build-Options is enabled by the package. However, we want build-arch and build-indep to be used *by default*. The maintainer should not need to take additional, explict, action in order to have them used. I therefore think autodetection is the most useful approach. In the meantime, we should encourage maintainers to pre-emptively adopt build-arch and build-indep, and could patch lintian to warn if not present. • Read-only root Depends on /run. Having /run will allow remaining writable files under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters). Identifying and fixing/removing packages writing to /etc during their normal operation would be a worthy release goal. This will make Debian more secure to run, easier to deploy in a cluster or netboot environment (no writable image overlay required), keeping dpkg-managed filesystems completely read-only during normal operation (other than /var). • /usr "removal" We should allow the installation and running of a system with no /usr (where /usr is a symlink to / for backward compatibility). Previously discussed on -devel. Initially, this is intended to be optional, keeping all dpkg-managed files on a single filesystem. In the future, we would have the option of dropping /usr entirely. Work needing doing: identification and removal of duplicate paths under / and /usr. If we want to support this on upgrades as well as new installs, upgrades need considering here as well. Support in debian-installer for disabling /usr would also be required. Also, tools such as dpkg-shlibdeps, ld etc. would need checking to make sure that building on such a system still results in packages which are installable on old-style split systems, e.g. when generating shlibs files etc. I'm sure I'll have more to come! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Description: Digital signature