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.
Attachment:
signature.asc
Description: Digital signature