>Steve McIntyre dixit: >>we think we may have found behaviour bugs too, >>but we can't be sure without spending even more effort. > >OK, just give me what you have, and I'll look at it, but I'm >pretty sure I checked them.
OK, I'm now even more miffed by pax because I've had to go through the
source code AGAIN and it makes less sense now than it did during the
BSP. Thanks for wasting yet more of my time.
0: mangling to suit your own tools:
dpkg-gencontrol -ppax -Pdebian/pax -isp
mv debian/pax/DEBIAN/control debian/B/c/
rm -rf debian/pax/DEBIAN
# goodbye dh_md5sums
(cd debian/pax && find . -type f | sed s,^./,, | sort | \
xargs md5sum) >debian/B/c/md5sums
That's just deliberately making things harder for any of your
*colleagues* who are supposed to be able to NMU your package. It is, as
the bug correctly states: insane. It cannot be justified or patched or
explained, it simply needs to be removed and done properly by
replacing all of that with just two lines. dh_gencontrol ; dh_md5sums
1: deliberate obfuscation for no benefit:
echo .nr g 2 | cat - cpio.1 | \
gzip -n9 >debian/pax/usr/share/man/man1/paxcpio.1.gz
Just add the extra top line to the upstream or create a patch already.
then you'd have something approaching sane:
cp cpio.1 debian/pax/usr/share/man/man1/paxcpio.1
gzip -n9 debian/pax/usr/share/man/man1/paxcpio.1
Even that is two lines repeated three times (once for each manpage)
instead of just dh_installman on a single line and a small .install
file but that just demonstrates the insanity of the current rules.
2: confused cross-building support:
ifneq (${DEB_BUILD_ARCH},${DEB_HOST_ARCH})
chown -R 0:0 debian/pax
endif
chmod 644 $$(find debian/pax -type f)
chmod 755 $$(find debian/pax -type d) \
debian/pax/bin/pax
I've done an awful lot of cross-building over the years, I've got no
idea why you think chown -R 0:0 is required only when cross-building.
Whatever you think the reasons are, it's not required. If you think it
is, you're doing it wrong.
3: The claimed reasoning for this NIH approach about the dependencies
of debhelper making it uninstallable is just wrong. The only extra
stuff required by debhelper is po-debconf and htmltext - a trivial
local rebuild would sort out those. The heavyweight dependency is
actually dpkg-dev (from which you use dpkg-architecture,
dpkg-gencontrol, dpkg-shlibdeps and dpkg-deb for cross-building).
dpkg-dev is just as complex a perl package as debhelper.
4: More obfuscation in the pax commands with which your typical Debian
maintainer will *not* be familiar. So your *colleagues* have to keep
trying to trace through the pax options to work out if it's doing it
right and whether the pax commands might need to change if things
change in dpkg-dev. (Note: not debhelper this time, dpkg-dev. The
authority on what goes into a Debian .deb is dpkg, not pax. That is not
up for negotiation, it's just reality.)
5: Avoidance of well tested debhelper (old or dh) support for no
particular reason.
Just fix it, yes? Current pax packaging is insane; de facto, done
deal, QED. Accept the peer review, stop playing around for your own
edification and just help everyone else get things done. Thanks already.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
pgpIxfjHkSYSe.pgp
Description: PGP signature
