On Thu, Apr 17, 2008 at 07:04:39AM -0400, Roberto C. Sánchez wrote: > On Thu, Apr 17, 2008 at 08:48:21AM +0100, Adam D. Barratt wrote: > > 2.10.25 should migrate to testing over the weekend, so hopefully a bpo > > package won't be too much longer. In the meantime it's fairly easy to > > backport yourself, as several people have already done, or simply copy the > > new script over from an unstable machine. Other than the update for the new > > .changes file format, there have been relatively little changes to debsign > > since the version in etch, and those have all been bugfixes. > > > IMO, that sort of misses the point. While I maintain quite a few > packages in Debian, the only places I run unstable/testing are in one VM > (for testing/reproducing/fixing bugs that I cannot reproduce in stable) > and in some chroots. The point is that I should be able to build my > packages inside of a pbuilder or other type of chroot, sign the package > on my host system and be reasonably sure that my package will be > accepted into the archive. If the archive software breaks compatibility > with the current stable release of (insert name of whatever tool is > affected, specifically devscripts in this case), then it looks bad on > Debian. You're mixing stable and unstable tools. You have to expect that you may run into incompatibilities -- that happens with feature development. As far as I know, we only require that *upgrades* from one stable release to the next stable release will work, not intermingling tools between them. The only thing about this that looks bad, IMO, is that we had some bad timing on uploads (which happens in unstable) and that we have developers who can't pay attention to debian-devel-announce. devscripts (and the debsign tool) is simply a convenience package and not having an up-to-date version of the package does not prevent you from doing your work. You can just as easily run dpkg-buildpackage in a chroot to build your packages and that has been generating proper signed .changes files the entire time. On the plus side, debsign is now more resilient to future changes in the Format of .changes files (as will mergechanges in the next upload). This only changes *when* the reject happens though (at debsign run instead of at upload), not whether it happens at all. Hopefully other tools which parse the .changes file have also learned from this experience and taken similar steps to prevent operating on Formats they don't understand. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
Attachment:
signature.asc
Description: Digital signature