retitle 690381 mksh, pax: please use a more common packaging style thanks Neil Williams dixit:
>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. Uhm, you could just have sent me whatever you had back then. >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 Indeed, but I do not want a B-D on debhelper here. I admit the B/c/ stuff has grown from histoic things (I’ve got a couple more packages not intended for Debian itself that do things this way), but why change what ain’t broken? >1: deliberate obfuscation for no benefit: >echo .nr g 2 | cat - cpio.1 | \ > gzip -n9 >debian/pax/usr/share/man/man1/paxcpio.1.gz This is no obfuscation. This is mostly because the upstream manpage has support for three different naming variants of the tools, and we use one other than the upstream default one in Debian. Normally, I’d just add -ng2 to an nroff call and preformat the manpage, but on GNU/Linux it seems to be common to not do that. I’ve seen other packages doing similar things, except like this: printf '.nr g 2\n.so cpio.1\n' >paxcpio.1; soelim paxcpio.1 That does the same, with more tools and less UNIX philosophy (note the nice use of the pipe and the hyphen-minus!). Besides, this is no packaging/debhelper issue. I had this here before not using debhelper any more. And this is the right way to go. >Just add the extra top line to the upstream or create a patch already. >then you'd have something approaching sane: Creating a patch against that manpage would even be more ridiculous, it would be like shooting with cannons on sparrows. Sorry, no. >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. Some sort of fakeroot stuff (to ensure that the files inside the data.tar.* member are owned by 0:0) which is always needed except we use the -M uidgid feature of pax to create the data.tar.* member which eliminates the need for root in the binary-* target. >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. Right. I was thinking of the amount of packages debhelper pulls in in total, which includes its, I think transitive closure is the term. >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 Nobody asks you to do that. I am keeping my packages in fairly good shape. And you can just assume it does its job. When I go fixing things in another’s package, I do not touch their build system either, for it normally just works. (Bugs against that very build system excepted, but I’ve seen none here yet.) >right and whether the pax commands might need to change if things >change in dpkg-dev. (Note: not debhelper this time, dpkg-dev. The I think that’s my job, as maintainer. >authority on what goes into a Debian .deb is dpkg, not pax. That is not >up for negotiation, it's just reality.) Right. And the support for .ar files was added to pax exactly *because* the more widely used tool to do that, GNU ar, was doing it wrong. >5: Avoidance of well tested debhelper (old or dh) support for no >particular reason. I agree with this one, but this is not enough for me to change that, especially not in deep freeze. >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. Which leads to: * Why were you investigating the build system of pax anyway? * It did pass e.g. the Ubuntu main inclusion peer review (in mksh). * Why are others still obfuscating good packaging for no reason by changing it to dh7 style, with '%:\n\tdh $@' rules files that are proven to make troubles (wildcard targets are BAD!)? I *am* fairly territorial wrt. my packages (those I do not comaintain) and will not just change this because someone else wants to… what, anyway? What did you want to do to pax? Why did nobody just talk to me first? I will change this if the current thing is proven to be unfit, or if a better alternative exists. But not now. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
