[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the Release Team - Kicking off Wheezy

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!


  .''`.  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

Reply to: