Re: dpkg plans for the squeeze cycle
Hi!
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).
regards,
guillem
Reply to: