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

Re: dpkg plans for the squeeze cycle


Sorry for the massive delay.

On Sun, 2009-08-16 at 14:41:15 +0200, Marc Brockschmidt wrote:
> Do you have any big changes planned? How much time would they take, and
> what consequences are there for the rest of the project?

There's a thread [0] on debian-dpkg with more detailed changes of what
we want to work on in the future, ideally those would be done for
squeeze, but most can be postponed, and there's only few we'd really
want to get done for squeeze, either because of the feature itself or
because they need a full release cycle to be usable:

 * Multiarch.

   I expect support for this in dpkg should be ready by the end of the
   month, there's needed code already in latest dpkg 1.15.4. As
   specified by the draft, the deployment should be incremental, so no
   major transition required.

 * Source format v3.

   Mostly waiting for ftp-master to merge the patch in DAK. Changes to
   the default format would need package to get fixed to not FTBFS.

 * Storage of conffile shipped in the .deb packages.

   The sooner we store them the more packages that will get those
   preserved at installation time. And then we can add support to do
   interesting stuff with them afterwards (in case it would have been
   too late for the release).

 * XZ compression support (to deprecate lzma).

   The lzma format will still be supported, though, always for
   extraction (as xz tools support it in a backward manner), probably
   disable lzma creation after a while.

 * Setting of build flags by dpkg-buildpackage.

   Finish discussion and implement a solution that the project can
   agree and live with.

[0] <http://lists.debian.org/debian-dpkg/2009/08/msg00022.html>

> How many "big" transitions will the upcoming changes cause?
> When should those happen? Can we do something to make them easier?

The only one I can see being problematic is the build flags one, there
might be packages that have started assuming dpkg-buildpackage will
set the flags, so they might fail or misbuild once it stops doing so.
The rest should be either internal to dpkg, or stuff that can be
incrementally deployed, so not a problem (barring bugs of course).


Reply to: