I've just read debian-devel, and: 0. Yes, all existing packages should now be converted to the new source format, and new packages should be in this format too.
1. Yes, dpkg-source doesn't work with hardlinks. I think that hardlinks in source packages are evil. Perhaps they can be made to work - Heiko's patch seems reasonable (until someone wants a filename containing the string ` link to '). However, I'd recommend just removing the hardlink and replacing it with a symlink (or just deleting one name). There is no problem with doing that, and it is fine wrt our policy about original sources. 2. I don't know what to do about tar doing nasty things to filenames. If this is a design feature of all tars then dpkg-source should be changed to unmangle the filename on output from tar. 3. Do NOT use Michael Meskes's patch to quote the argument to $rootcommand in dpkg-buildpackage. Instead, RTFM. Please DO NOT release a dpkg with Michael Meskes's patch. Thank you. 4. dpkg-name belongs in the dpkg-dev package. If anyone is releasing a new dpkg they should move it. See debian/rules. 5. I don't understand the problem with WIFSIGNALED, but this is definitely a bug in the Perl installation and not in dpkg-source. 6. Karl Sackett's fix for an error message typo (Bug 4524) is good. Heiko, please close the report if you like but definitely mail me the patch. 7. Ives Arrouye asked about `Source: php' / `Package: php-module'. This will work but you have to give dpkg-gencontrol the -p option. There should be no need to have one of the binary packages named the same as the source. 8. Regarding dpkg-shlibdeps: every shared library package should provide a `shlibs' file for the libraries it contains. This is put in the DEBIAN directory when the package is built, and will end up in /var/lib/dpkg/info/<pkg>.shlibs when it is installed. dpkg-shlibdeps looks there (but earlier versions had a bug). The /etc/dpkg/shlibs.local file is only there to sort things out with the most basic packages before they have shlibs files in the shared library packages. Documentation for this is available. If you find that your package needs a shared library package which doesn't have the dpkg-shlibdeps support why not convert it now ? See the section on other-than-usual-maintainer releases in the policy manual. 9. On permissions of maintainer scripts - this has affected libpng at least: dpkg-source honours the extracter's umask, unlike tar. The debian/rules file should explicitly set the permissions and not rely on (say) cp to copy them correctly. 10. Re dpkg-buildpackage and the failure to build due to permissions (bug 4525). I'm inclined to say "don't build with a umask of 077 then". I don't think that all packages' debian/rules should be responsible for fixing the permissions of the created files. 11. Christian Schwartz posted a Perl script that (I presume) produces much the same output as sed -e 's/ +/ /' | sort +2 does on the Maintainers file in the indices subdirectory of the ftp site. 12. llucius posts a patch to dpkg-buildpackage to make it pass -v, -m and -C to dpkg-genchanges. His patch is not in line with my intent, and won't work when the arguments have spaces. The call to dpkg-genchanges needs to read withecho dpkg-genchanges $sourcestyle "$@" >"$chg" instead of the thing in his patch. (Bug #4554.) I hope this is enough to keep you going for another week :-). Ian.
