On Sun, 25 Nov 2012 23:38:04 +0000 (UTC) Thorsten Glaser <t...@mirbsd.de> wrote:
> >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. If there is to be a sane fix to this bug, then debhelper is precisely what is being required. This isn't about your wishlist, it's about allowing others to work on the package during a release freeze. > 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? It *is* broken - it makes your package nigh on impossible for anyone to work on except you. You are replaceable and pax is not *your personal package* - it is in Debian, everyone with upload rights needs to be able to at least work out if the package is sane. > >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. Then document it in the rules file. > 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. It adds to the mess in debian/rules - simplification is the goal of this bug. > >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. Not good enough. You complain about what other developers think about your packaging, saying it's "not broken" but then don't provide your own evidence to backup your own breakage but hide behind "some sort of fakeroot stuff". There is no fakeroot problem with cross-building. It's a fault generated by your non-standard use of pax and the whole B/c/ misdirection. There is no reason to use pax to build the pax .deb. (If anything, it makes things harder because it makes pax a circular dependency on itself. The current packaging admits as much by using dpkg-deb when cross-building when what you *mean* is to use dpkg-deb when *bootstrapping* in order to break this self-imposed circular dependency.) > >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. OK, so you agree that the dependencies of debhelper are *not* a reason to not use debhelper in your own packages. debhelper does *not* bring in any more packages than dpkg-dev does, apart from those required by htmltext and po-debconf. In a clean chroot with dpkg-dev installed, installing debhelper only adds: bsdmainutils debhelper file gettext gettext-base groff-base html2text intltool-debian libasprintf0c2 libcroco3 libffi5 libgettextpo0 libglib2.0-0 libmagic1 libpcre3 libpipeline1 libunistring0 libxml2 man-db po-debconf Of those, po-debconf is responsible for: gettext gettext-base intltool-debian libasprintf0c2 libcroco3 libffi5 libgettextpo0 libglib2.0-0 libpcre3 libunistring0 libxml2 po-debconf and man-db for: bsdmainutils groff-base libpipeline1 man-db If you are serious about dependency problems, this is what you would get because you'd be turning Recommends off - e.g. as in a buildd chroot. root@sylvester:/# cat /etc/apt/apt.conf.d/15pbuilder APT::Install-Recommends "false"; Then simply rebuild debhelper with a local change to drop po-debconf and what slight dependency issue may exist has just "gone away". See? > >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. Debian asks us to do that, the release team asked us to do that, the Debian BTS invited us to do that - the current DPL has already explained why this is necessary. This bug arose precisely because there was a bug in pax which drew the attention of other DD's at a BSP for Wheezy. > I am keeping my packages in fairly > good shape. If that was true, we would not have looked at pax during the BSP. > 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. Your build system for pax is unintelligible to others - we can't tell if it works properly or not. That's the problem. We didn't NMU pax partly because we couldn't work out how to fix it. That is not acceptable in Debian because, believe it or not, you are replaceable and one of us will have to fix pax when that happens. If this bug is still open, the only sane fix is RM. > (Bugs against that > very build system excepted, but I’ve seen none here yet.) Your build system is actively preventing others working on your package. That is a bug. > >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. See Zack's email, again. Debian cannot rely on you always being available. The only option then would be to RM the package. > >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. Then show some engagement with your peers and fix it in experimental. > * Why were you investigating the build system of pax anyway? It came up on the list of bugs to investigate at the BSP. Why is it a problem for you that your peers wanted to look at pax? > * It did pass e.g. the Ubuntu main inclusion peer review (in mksh). It has failed Debian peer review. Ubuntu may have different requirements or just less time to show you the error of your ways. Peer review may be intermittent in Debian (largely provoked by RC bugs) but it does happen and, look, it just has - to pax. It's failed, please fix it. ftpmaster does some checking of the package when it goes through NEW but any package in Debian is subject to the scrutiny of Debian at any time. If you don't want that, take the package out of any archive to which other Debian Developers have upload rights. > * 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!)? Not your problem. Use old style debhelper if you dislike dh7 so much. I do. That there isn't one size to suit them all is NOT sufficient reason to implement another set just for a handful. There are multiple well-tested alternatives available - debhelper supports two. There is no reason for pax not to use debhelper as your personal preferences do not outweigh the needs of Debian as a whole. > I *am* fairly territorial wrt. my packages (those I do not comaintain) That is the entire problem and that attitude is not welcome in Debian. These packages need to allow other Debian Developers to understand what is going on and to implement fixes in the packaging. pax fails this test. Maintainers are responsible for their packages *on behalf of Debian*. Responsibility does NOT imply ownership or exclusion of your peers. If I cared about pax at all, I'd be preparing a hostile NMU purely on the basis of that one statement, using old style debhelper and sane (fully tested) cross-building support. I'd be more than happy to discuss genuine bugs which may arise from that via the Technical Committee. As it is, I don't care about pax other than it reflects badly on the rest of Debian - that's almost justification for an RM. I'm willing to escalate that, if this bug isn't fixed. If you object to that and don't fix the bug, maybe the Technical Committee is the right place to get a decision. > 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? These are not *your* packages, these are Debian packages. If you want them to be your private territory then RM them from Debian and put them in a repository to which the rest of us do not have upload rights. You may be maintainer but maintainers can disappear, be replaced or have their packages NMU'd. No package is your personal fiefdom. This bug *is* the Debian-approved way of talking to the maintainer! What this bug requires is that pax moves to a sane, well-tested build system and the one being strongly recommended is old-style debhelper as you seem to dislike dh7. I use old-style debhelper too, there's nothing wrong with that. Your peers understand it and it is well tested and easy for your others to help you fix bugs. > I will change this if the current thing is proven to be unfit, or if > a better alternative exists. But not now. The current package is unfit due to it being sufficiently non-standard that your peers cannot work out if it is working correctly. A better alternative has existed since Woody - it's called debhelper. You don't have to use dh7, just use old style debhelper and everyone will be able to work on pax. Please drop this territorial obstinacy. This is a Debian package, it needs to be worked on by anyone in Debian with upload rights. It needs sane packaging because you are *replaceable* and could disappear or be out of contact for any reason at any time for any reason. RealLife is like that, unexpected stuff happens and no one can guarantee they will be around to fix stuff themselves. Please, read Zack's email again - pax needs to be changed to make it something which your *peers* can work on and fix. Right now, we cannot. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgp8QpOuWsBbr.pgp
Description: PGP signature
