Eric,
It was brought to my attention (because of an overzealous test in one of
Debian packaging tools was recently re-activated) that fetchmail tarballs do
not include subdirectory entries for the subdirectories they contain.
i.e.: you have:
foo/1 (file)
foo/bar/2 (file)
as files inside the tarball, instead of:
foo (directory)
foo/1 (file)
foo/bar (directory)
foo/bar/2 (file)
Apparently the test exists because there are some vendor tar programs that
are stupid enough to fail to create the subdirectories if they are not
included in the tar file, and dpkg is supposed to run in systems without GNU
tar, maybe so as to enable one to install GNU tar from a Debian package :)
Anyway, I can work around the problem in my end (the overzealous dpkg-source
tool) very easily: I'll simply export and repack the tarballs after
importing your new upstream source into CVS. No matter how broken a system
without GNU tar is by definition (I like GNU tools, so what? :) ), I decided
to bring the problem to your attention since it might mean the fetchmail
tarballs cannot be oppened by certain tar implementations (no, I do not know
which ones... but then, you support non-GNU gettext too).
BTW, directory-less tar files are created because you give GNU tar the files
it should pack, instead of packing the whole subtree. As a possible
workaround, I suggest using cvs export or something like that to keep
control of the files that will be inserted into the tarball, while still
telling tar to pack the entire subtree. Or maybe cp'ing (or tar -cf -
<files> | tar -xf -'ing) the MANIFEST-listed files to a temporary
fetchmail-($version) subtree, and packing that subtree as the .tar.gz file
to be distributed.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh