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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
