dpkg changes and queries - the answers to your questions
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.
Reply to: