Debian Bug report logs - #690381
mksh, pax: please use a more common packaging style

version graph

Package: pax; Maintainer for pax is Thorsten Glaser <tg@mirbsd.de>; Source for pax is src:pax.

Reported by: Steve McIntyre <steve@einval.com>

Date: Sat, 13 Oct 2012 15:00:01 UTC

Severity: wishlist

Tags: wontfix

Found in version pax/1:20120605-1

Fixed in versions pax/1:20120606-3, mksh/40.9.20121124-2

Done: Thorsten Glaser <tg@mirbsd.de>

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Sat, 13 Oct 2012 15:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve McIntyre <steve@einval.com>:
New Bug report received and forwarded. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Sat, 13 Oct 2012 15:00:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Steve McIntyre <steve@einval.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Insane debian/rules
Date: Sat, 13 Oct 2012 15:57:57 +0100
Package: pax
Version: 1:20120605-1
Severity: important

It seems the change

  * Build-Depends less package! Thanks to “goodbye” sample package!

includes switching from the well-understood set of calls to debhelper
and dpkg-dev programs to something hand-rolled. Please *don't* do
this; it's not explicitly required by policy that packagers use these
programs, but please consider when other developers might need to work
on your package (NMUs for important fixes, security updates
etc.). The current package setup is going to cause pain.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sat, 13 Oct 2012 15:24:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sat, 13 Oct 2012 15:24:06 GMT) Full text and rfc822 format available.

Message #10 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: 690381@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sat, 13 Oct 2012 15:10:52 +0000 (UTC)
severity 690381 wishlist
tags 690381 + wontfix
thanks

Steve McIntyre dixit:

>includes switching from the well-understood set of calls to debhelper
>and dpkg-dev programs to something hand-rolled. Please *don't* do
>this; it's not explicitly required by policy that packagers use these
>programs, but please consider when other developers might need to work
>on your package (NMUs for important fixes, security updates
>etc.).

Right. On the other hand, all those things you mentioned will not touch
the areas where debhelper is not used, and I’ve seen worse, such as dh7
('%:\n\tdh $@'), cdbs and Manoj’s buildsystem (no offence).

>The current package setup is going to cause pain.

I respectfully disagree. However, I’ll probably not use it for any
more packages safe these which already use it.

bye,
//mirabilos
-- 
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success 18:35⎜<asarch> "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent



Severity set to 'wishlist' from 'important' Request was from Thorsten Glaser <tg@mirbsd.de> to control@bugs.debian.org. (Sat, 13 Oct 2012 15:24:07 GMT) Full text and rfc822 format available.

Added tag(s) wontfix. Request was from Thorsten Glaser <tg@mirbsd.de> to control@bugs.debian.org. (Sat, 13 Oct 2012 15:24:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Sat, 13 Oct 2012 17:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve McIntyre <steve@einval.com>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Sat, 13 Oct 2012 17:15:05 GMT) Full text and rfc822 format available.

Message #19 received at 690381@bugs.debian.org (full text, mbox):

From: Steve McIntyre <steve@einval.com>
To: Thorsten Glaser <tg@mirbsd.de>, 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sat, 13 Oct 2012 18:10:45 +0100
On Sat, Oct 13, 2012 at 03:10:52PM +0000, Thorsten Glaser wrote:
>severity 690381 wishlist
>tags 690381 + wontfix
>thanks
>
>Steve McIntyre dixit:
>
>>includes switching from the well-understood set of calls to debhelper
>>and dpkg-dev programs to something hand-rolled. Please *don't* do
>>this; it's not explicitly required by policy that packagers use these
>>programs, but please consider when other developers might need to work
>>on your package (NMUs for important fixes, security updates
>>etc.).
>
>Right. On the other hand, all those things you mentioned will not touch
>the areas where debhelper is not used, and I’ve seen worse, such as dh7
>('%:\n\tdh $@'), cdbs and Manoj’s buildsystem (no offence).
>
>>The current package setup is going to cause pain.
>
>I respectfully disagree. However, I’ll probably not use it for any
>more packages safe these which already use it.

Right. I can see that mksh also follows a similar pattern. Any other
packages?

FWIW, I've just taken a straw poll of the people around me at a BSP
and the consensus of all the people here is "that's insane". Trying to
work out what your builds are trying to do took several minutes of
close reading for us; we think we may have found behaviour bugs too,
but we can't be sure without spending even more effort.

Please reconsider your approach - the point of working in Debian on
packaging software is to make a nicely-integrated operating system,
*not* to try and show just how clever you can be with obfuscating what
you're working on.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Who needs computer imagery when you've got Brian Blessed?




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sat, 13 Oct 2012 17:48:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sat, 13 Oct 2012 17:48:09 GMT) Full text and rfc822 format available.

Message #24 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Steve McIntyre <steve@einval.com>, 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sat, 13 Oct 2012 17:34:18 +0000 (UTC)
Steve McIntyre dixit:

>Right. I can see that mksh also follows a similar pattern. Any other
>packages?

Only these two, out of the packages I intended for uploading to
Debian proper.

>and the consensus of all the people here is "that's insane". Trying to
>work out what your builds are trying to do took several minutes of
>close reading for us

Fun, the Ubuntu main inclusion process people thought it was
obscure but okay, and the comments pretty much hint at which
debhelper commands they replace.

>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.

>Please reconsider your approach

Maybe we need something like debhelper-lite in the archive,
post-wheezy. Have you seen what a dependency monster it became,
and what insane number of commands it runs for each build?
Also, every dh_* command first runs lots of other code, both
internally in Perl as well as via spawned processes, redundantly.

On slower buildds, not using debhelper cut down noticeable.

Not to mention that there's almost no magic behind the curtains
with this method.

Why don't you go forward and fix the RC bugs in dash that
prevent other shells from using /bin/sh in a natural way
instead?

bye,
//mirabilos, still sneezing too much
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (251 (271) bugs: 1 (2) RC, 175 (189) I&N, 75 (80) M&W, 0 F&P)
‣ src:dash (78 (90) bugs: 4 RC, 32 (36) I&N, 42 (50) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?



Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Sun, 14 Oct 2012 15:12:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefano Zacchiroli <zack@debian.org>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Sun, 14 Oct 2012 15:12:06 GMT) Full text and rfc822 format available.

Message #29 received at 690381@bugs.debian.org (full text, mbox):

From: Stefano Zacchiroli <zack@debian.org>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: 690381@bugs.debian.org, Steve McIntyre <93sam@debian.org>
Subject: Re: Bug#690381: Insane debian/rules
Date: Sun, 14 Oct 2012 17:09:22 +0200
[Message part 1 (text/plain, inline)]
On Sat, Oct 13, 2012 at 03:10:52PM +0000, Thorsten Glaser wrote:
> >includes switching from the well-understood set of calls to debhelper
> >and dpkg-dev programs to something hand-rolled. Please *don't* do
> >this; it's not explicitly required by policy that packagers use these
> >programs, but please consider when other developers might need to work
> >on your package (NMUs for important fixes, security updates
> >etc.).

I'd like to AOL the above. Using "non-standard" build systems might be
very cool for those working with them today, or might address some very
specific need (such the one you mentioned: building on very slow build
systems), but in the long run they induce a potentially severe community
cost. If you one day stop caring about Debian, for whatever reason,
those who come after you will have to spend more effort understanding
what's going on than "needed". The case of NMUs is a degenerate case of
the very same problem: you might be temporarily unavailable and people
might have to fix a serious bug in your package to kick out a release
(which is in fact, exactly what happens during BSPs). Using something
more "standard" in your package helps tremendously those people who,
ultimately, just want to help you out.

A principle I recommend following in Debian is: make yourself as
replaceable as possible, because sooner or later someone will have to
step in your shoes. We might not see it today, but it will have to
happen, eventually.

> Right. On the other hand, all those things you mentioned will not touch
> the areas where debhelper is not used, and I’ve seen worse, such as dh7
> ('%:\n\tdh $@'), cdbs and Manoj’s buildsystem (no offence).

Sure, but two wrongs don't make one right, ... right? :) Manoj's
buildsystem hasn't seem a lot of love among other people who had to
touch his packages, precisely for that reason. All in all, that might
have also reduced the potential contributions by others that those
packages could have received if something more standard were used.

Please, think of the kittens :).
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sun, 14 Oct 2012 15:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sun, 14 Oct 2012 15:33:06 GMT) Full text and rfc822 format available.

Message #34 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Stefano Zacchiroli <zack@debian.org>
Cc: 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sun, 14 Oct 2012 15:31:20 +0000 (UTC)
Stefano Zacchiroli dixit:

>(which is in fact, exactly what happens during BSPs). Using something
>more "standard" in your package helps tremendously those people who,
>ultimately, just want to help you out.

Right, but there are three points still:

• At some point in time, I really needed mksh to build on some
  debian-ports architectures that had debhelper (the dependency
  monster, nowadays) uninstallable, to test fixes mostly in
  either dietlibc (which also uses pre-debhelper packaging, and
  I think is less clean than my 'goodbye'-inspired experiment)
  or klibc. This really helped.

• I still think this is more easy to touch than dh7 style.

  Or all of the other named ones, but, as you say, they also
  don’t get any love, or (cdbs) much less.

• debhelper-lite isn’t going to be introduced for wheezy, *and*
  I’m not going to make intricate packaging changes now (even
  if they’re probably without issues), as the release team almost
  certainly hates me already anyway

I’d not have uploaded these packages if I wasn’t sure they work,
and usually I prototype my packages in private repositories for
up to months. Still, if sledge would please give me a hint at
what they thought they found, I'll look at it. It's not as if
I were unapproachable (though I *am* a bit territorial about my
packages, considering the move to stuff like dh7 recently, even
though I often help out packages in other styles, as to not close
my eyes or ideology).

Admittedly, using pax instead of dpkg-deb may be a bit over the
top, but it allows rootless builds *and* is, for the pax package
itself, a test that it really works.

If joeyh is interested, I’ll try to talk about debhelper-lite
next year. The basic idea behind this is: debhelper has gained
so much and is so universal that it’s not really suitable for
most small packages (shooting with cannons at small birds, and
all that).

Sorry if some of my sentences don't make as much sense as they
should, I’ve still not fully recovered.



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sun, 25 Nov 2012 20:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sun, 25 Nov 2012 20:09:03 GMT) Full text and rfc822 format available.

Message #39 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Steve McIntyre <steve@einval.com>, 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sun, 25 Nov 2012 20:02:36 +0000 (UTC)
Dixi quod…

>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.

I can't help but notice I never received even the vaguest
detail on the “we think we may have found” part so I could
have analysed these myself.

Just saying.

bye,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh



Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Sun, 25 Nov 2012 20:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve McIntyre <steve@einval.com>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Sun, 25 Nov 2012 20:51:03 GMT) Full text and rfc822 format available.

Message #44 received at 690381@bugs.debian.org (full text, mbox):

From: Steve McIntyre <steve@einval.com>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sun, 25 Nov 2012 20:47:15 +0000
On Sun, Nov 25, 2012 at 08:02:36PM +0000, Thorsten Glaser wrote:
>Dixi quod…
>
>>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.
>
>I can't help but notice I never received even the vaguest
>detail on the “we think we may have found” part so I could
>have analysed these myself.

Sorry, totally forgot to get back to you. I was hoping that the others
from that BSP would give me the list, but nothing yet. Give me a few
more days...

I *do* still stand by the initial comments, regardless.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Is there anybody out there?




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sun, 25 Nov 2012 21:09:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sun, 25 Nov 2012 21:09:05 GMT) Full text and rfc822 format available.

Message #49 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Steve McIntyre <steve@einval.com>
Cc: 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Sun, 25 Nov 2012 20:58:53 +0000 (UTC)
Steve McIntyre dixit:

>Sorry, totally forgot to get back to you. I was hoping that the others
>from that BSP would give me the list, but nothing yet. Give me a few
>more days...

OK, no problem.

>I *do* still stand by the initial comments, regardless.

Understood.

bye,
//mirabilos
-- 
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.



Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Sun, 25 Nov 2012 23:15:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Sun, 25 Nov 2012 23:15:06 GMT) Full text and rfc822 format available.

Message #54 received at 690381@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: 690381@bugs.debian.org
Cc: Steve McIntyre <steve@einval.com>
Subject: Insane packaging of pax
Date: Sun, 25 Nov 2012 23:13:32 +0000
[Message part 1 (text/plain, inline)]
>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/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sun, 25 Nov 2012 23:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sun, 25 Nov 2012 23:45:04 GMT) Full text and rfc822 format available.

Message #59 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Neil Williams <codehelp@debian.org>, 690381@bugs.debian.org
Cc: Steve McIntyre <steve@einval.com>, control@bugs.debian.org
Subject: Re: Bug#690381: Insane packaging of pax
Date: Sun, 25 Nov 2012 23:38:04 +0000 (UTC)
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



Changed Bug title to 'mksh, pax: please use a more common packaging style' from 'Insane debian/rules' Request was from Thorsten Glaser <tg@mirbsd.de> to control@bugs.debian.org. (Sun, 25 Nov 2012 23:45:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Sun, 25 Nov 2012 23:57:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Sun, 25 Nov 2012 23:57:07 GMT) Full text and rfc822 format available.

Message #66 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane packaging of pax
Date: Sun, 25 Nov 2012 23:45:52 +0000 (UTC)
Dixi quod…

>I will change this if the current thing is proven to be unfit, or if
>a better alternative exists. But not now.

For what it’s worth, I asked because someone said possible behaviour
bugs. I don’t see a single hint of that in your list. Maybe the one
with chown 0:0 may be perceived as one, but you said it was never
required, so that’s out too.

Another thing is, I’m not totally closed to talking about making
better alternatives, I brought up the idea of a debhelper-lite
myself already. But not now. You’ve got a release to do, and I’d
like the RC bugs in dash gone, for one, so that mksh can be used
as /bin/sh without a manual “sudo ln -sf mksh-static /bin/sh”.
Goswin made a proposal for it, even (no feedback from the bash
maintainer on this at all). Or, just RoQA dash… what I should be
trying to say (it’s obscenely late and I probably shouldn’t rant
here but go to sleep) is, we all have other things to do, it does
its job quite well and the people responsible for it do not have
a problem with that.

Good night,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (253 (273) bugs: 1 (2) RC, 176 (190) I&N, 76 (81) M&W, 0 F&P)
‣ src:dash (80 (93) bugs: 4 RC, 35 (39) I&N, 41 (50) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?



Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Mon, 26 Nov 2012 09:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Mon, 26 Nov 2012 09:09:03 GMT) Full text and rfc822 format available.

Message #71 received at 690381@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: tg@mirbsd.de
Cc: 690381@bugs.debian.org, steve@einval.com
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 09:04:44 +0000
[Message part 1 (text/plain, inline)]
On Sun, 25 Nov 2012 23:38:04 +0000 (UTC)
Thorsten Glaser <tg@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/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Mon, 26 Nov 2012 10:33:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Mon, 26 Nov 2012 10:33:09 GMT) Full text and rfc822 format available.

Message #76 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Neil Williams <codehelp@debian.org>
Cc: 690381@bugs.debian.org, steve@einval.com
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 10:21:05 +0000 (UTC)
Neil Williams dixit:

>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.

Somewhat, yes. But I am still the maintainer, and doing things.

>It adds to the mess in debian/rules - simplification is the goal of
>this bug.

I don’t care about *over*simplification, especially at the expense
of hidden complexity and massive speed loss.

Furthermore, by not using debhelper, I know exactly what’s going on.
cdbs and dh7 are even worse because they hide precisely that.

>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.

The only thing you could say here is that the chown call is not
necessary at all, but I’ve yet to see it hurting (I did test
cross-building). If it’s just redundant, I don’t *need* to remove
it. It’s certainly less overhead than installing debhelper.

>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.)

No, because, for a native build, at that poing, pax is already
available. In fact, this is a test for pax, and it has found a
bug in fakeroot precisely *because* the pax just built is used
to create its own package. Nothing circular in there.

>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.

(I always turn them off.)

>Then simply rebuild debhelper with a local change

No, that would break other builds.

>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.

What bug? Nobody said something about a bug.

>> 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.

If you show some peer love and get rid of dh7 or cdbs in
some other package, I’m willing to make that deal.

>> * Why were you investigating the build system of pax anyway?
>
>It came up on the list of bugs to investigate at the BSP.

The build system? I am not aware of a bug against that.

>Why is it a problem for you that your peers wanted to look at pax?

That’s not the problem. The problem is that I’m being steamrolled
over with no notice beforehand, and with no (to me) visible reason.

>> 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.

Debian is a do-ocracy, and you can’t say I’m doing nothing.
Also, it has traditionally, and recently, upheld strong package
maintainership, so this is even a customary law. I don’t care
whether this attitude is not welcome for *you* but it matches
what is practiced in Debian. I’m just stating it explicitly.

>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

Excuse me? Now you’re getting ridiculous.

>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

I suggest you go for packages that use, e.g. Manoj’s system and dbs
next, then cdbs after that. Please. Otherwise you’re singling out my
(working, well-tested, simple) build system, which I cannot help but
feel as if it were a personal affront against my person (it probably
is not, but the message arrives here like that, and I can’t control
my feelings).

>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.

Again, right now, nobody has told me why they should want to.

(Note, fixing things in the code, not packaging, is easy. I even
use 3.0 (quilt) nowadays.)

bye,
//mirabilos
-- 
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.



Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Mon, 26 Nov 2012 12:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Mon, 26 Nov 2012 12:03:03 GMT) Full text and rfc822 format available.

Message #81 received at 690381@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: 690381@bugs.debian.org, steve@einval.com
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 12:01:13 +0000
[Message part 1 (text/plain, inline)]
On Mon, 26 Nov 2012 10:21:05 +0000 (UTC)
Thorsten Glaser <tg@mirbsd.de> wrote:

> Neil Williams dixit:
> 
> >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.
> 
> Somewhat, yes. But I am still the maintainer, and doing things.

That cannot be guaranteed - at some point, someone else is going to
need to work on pax. The build system is non-standard and not well
tested because it's restricted to only two packages.

If that turns out to be me, I will RM. I'm not going to spend time on
the current insanity.
 
> Furthermore, by not using debhelper, I know exactly what’s going on.
> cdbs and dh7 are even worse because they hide precisely that.

Use old-style debhelper. Are you trying to say that dh_shlibdeps hides
things more than dpkg-shlibdeps does? Or that dh_gencontrol hides
things compared to dpkg-gencontrol?

How is it helpful if you *and only you* know what is going on?

> >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.
> 
> The only thing you could say here is that the chown call is not
> necessary at all, but I’ve yet to see it hurting (I did test
> cross-building). If it’s just redundant, I don’t *need* to remove
> it. It’s certainly less overhead than installing debhelper.

It's confusing and misleading. It adds to the obfuscation of the
package. It would appear to be an artefact of the insane build system
itself, therefore the fix is to not use pax in it's own packaging.
 
> >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.)
> 
> No, because, for a native build, at that poing, pax is already
> available. In fact, this is a test for pax, and it has found a
> bug in fakeroot precisely *because* the pax just built is used
> to create its own package. Nothing circular in there.

The pax just built is going to be for the wrong architecture. I don't
see any attempt to build for DEB_BUILD_GNU_TYPE and then rebuild with
DEB_HOST_GNU_TYPE for the final packaging. You can't run an armel
(HOST) binary on amd64 (BUILD). So the cross-build for armel depends on
itself (amd64) which is not helpful, especially as it is completely
unnecessary. There is no need to use pax in it's own buildsystem. This
is common for interpreted languages but it is still a problem and it is
completely unnecessary for pax. By doing so, you are deliberately being
awkward to those who may end up bootstrapping a new architecture.

> >Then simply rebuild debhelper with a local change
> 
> No, that would break other builds.

Rubbish. A local change to drop po-debconf from the dependencies
of debhelper does not affect other builds in any way. Complete
nonsense. 

> >Why is it a problem for you that your peers wanted to look at pax?
> 
> That’s not the problem. The problem is that I’m being steamrolled
> over with no notice beforehand, and with no (to me) visible reason.

Your packaging is impenetrable to those who would need to fix it when
you are not around. That is sufficient reason. There is no need for a
notice period before a bug is filed and Debian does these sort of
things in public, so a bug report is perfectly acceptable.

> >> 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.
> 
> Debian is a do-ocracy, and you can’t say I’m doing nothing.

I'm not saying anything like that - I'm saying that nobody can
guarantee their own availability into the future. Just because you're
responding now, doesn't mean you will be when someone else needs
something fixed in pax. That's why we have NMU's - your package is IMHO
not NMU-able because the build system is insane. That's why, if I had
to work on something in pax whilst you weren't around for whatever
reason, my only option would be to RM. It's better that I declare that
now than for you to come back from some period of illness or whatever
and find the package removed. This bug report is asking that you
prevent that situation occurring.

> Also, it has traditionally, and recently, upheld strong package
> maintainership, so this is even a customary law. I don’t care
> whether this attitude is not welcome for *you* but it matches
> what is practiced in Debian. I’m just stating it explicitly.

Strong package maintainership does not give you sole rights over the
package. Others have to be able to work on it as well. When your peers
complain that the package is not understandable, the standard reaction
from a package maintainer would be to fix the problem.

Just because you can do insane packaging, does not mean you should.
 
> >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
> 
> I suggest you go for packages that use, e.g. Manoj’s system and dbs
> next, then cdbs after that. Please. Otherwise you’re singling out my
> (working, well-tested, simple) build system

Nobody else but you can tell if it's working. It's not well tested
compared to debhelper because only 2 packages use it instead of, I
don't know, maybe 20,000?

>, which I cannot help but
> feel as if it were a personal affront against my person (it probably
> is not, but the message arrives here like that, and I can’t control
> my feelings).

We all have to control our feelings. This is about the insanity of
pax packaging, nothing else.
 
> >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.
> 
> Again, right now, nobody has told me why they should want to.

It doesn't matter why we should want to, the package will need to be
worked on by someone else at some point. It is inevitable. Nothing you
say can avoid that - if it's in this state when that happens, the only
sane response would be RM.

> (Note, fixing things in the code, not packaging, is easy. I even
> use 3.0 (quilt) nowadays.)

I noticed, that's how I tested the manpage patch. If you use
well-tested tools used by thousands of other packages, you get results
that others can validate and test without having to ask you. Your peers
shouldn't NEED to file a bug against your build system just so that
your build system can be understood!

Just what is wrong with old-style debhelper like:

binary-arch: build install
	dh_testdir
	dh_testroot
	dh_installchangelogs 
	dh_installdocs
	dh_installman
	dh_install --exclude=.svn
	dh_link
	dh_strip --dbg-package=foobar-dbg
	dh_compress
	dh_fixperms
	dh_makeshlibs
	dh_installdeb
	dh_shlibdeps
	dh_gencontrol
	dh_md5sums
	dh_builddeb

?

Nothing unnecessary is called (one of my pet gripes with cdbs and dh7),
everything is done in a clear order and the details are all in suitable
places - like the .install files where every other packaging system
looks for them.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Mon, 26 Nov 2012 16:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Mon, 26 Nov 2012 16:33:06 GMT) Full text and rfc822 format available.

Message #86 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Neil Williams <codehelp@debian.org>, 690381@bugs.debian.org
Cc: steve@einval.com, debian-bugs-dist@lists.debian.org
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 16:24:32 +0000 (UTC)
Neil Williams dixit:

>How is it helpful if you *and only you* know what is going on?

It’s better when the responsible person and noone else knows
what’s going on than when the responsible person doesn’t know
what’s going on.

>> bug in fakeroot precisely *because* the pax just built is used
>> to create its own package. Nothing circular in there.
>
>The pax just built is going to be for the wrong architecture. I don't
>see any attempt to build for DEB_BUILD_GNU_TYPE and then rebuild with

It uses dpkg-deb in the cross case. Hence, the chown.

>something fixed in pax. That's why we have NMU's - your package is IMHO
>not NMU-able because the build system is insane. That's why, if I had

When you work on the code (opposed to the packaging), all you have
to do is drop in a quilt patch or more, run dch --nmu, dpkg-buildpackage
and you’re set. That’s Debian standard.

>to work on something in pax whilst you weren't around for whatever
>reason, my only option would be to RM. It's better that I declare that

That is absolutely, utterly ridiculous. Really.

Will you RM all packages using, say (again, Manoj, if you read this,
nothing against you, just using it as an example) Manoj’s buildsystem?
Or dbs? If not, why not?

>Just what is wrong with old-style debhelper like:

Not much, other than the time a cowbuilder actually spends building
the code, versus the time spent installing the B-D and doing several
debhelper operations which – on m68k, this is *very* noticeable – run
the same code over and over with each invocation (dh7 doesn’t even
improve this *despite* calling only one dh binary, asides from it
calling… dh_installgintrospection or something like that, and similar…
funny stuff).

And that’s what I’ll be uploading to experimental later. Despite
that, I state here, for the record, that I believe I am entitled
to do this.

Oh, another thing that’s “wrong” with it: I wanted to build mksh on
architectures where debhelper – or anything Perl, for that matter –
is not installable, in order to test my fixes to dietlibc and klibc
on them. Yes, these are Debian-Ports architectures which I guess you,
in the best case, don’t care about, and in the worst case, to cite
another RT member, don’t want to see any “more Debian-Ports spam”.
But I care about my core, beyond what’s in a released Debian at any
given point. (Hell, I even deal with Launchpad, *buntu user bugreports,
file sync and merge requests, and all that.)

Maybe this sheds some light on my motivation. (Besides that, I still
build current mksh as packaged, with minimal patches, for systems as
old as sarge and dapper, though etch and hardy are the oldest respective
ones really in use at the moment.)

bye,
//mirabilos
-- 
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.



Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Mon, 26 Nov 2012 17:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Neil Williams <codehelp@debian.org>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Mon, 26 Nov 2012 17:42:03 GMT) Full text and rfc822 format available.

Message #91 received at 690381@bugs.debian.org (full text, mbox):

From: Neil Williams <codehelp@debian.org>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: 690381@bugs.debian.org, steve@einval.com
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 17:39:09 +0000
[Message part 1 (text/plain, inline)]
On Mon, 26 Nov 2012 16:24:32 +0000 (UTC)
Thorsten Glaser <tg@mirbsd.de> wrote:

> >Just what is wrong with old-style debhelper like:
> 
> Not much, other than the time a cowbuilder actually spends building
> the code, versus the time spent installing the B-D and doing several
> debhelper operations which – on m68k

m68k is not a Debian architecture, it's requirements don't matter to
the rest of Debian. Keep a fork of your code in a local repo for m68k,
don't contaminate the rest of Debian with artificial requirements which
have nothing to do with Debian release architectures.

Believe it or not, I've done as much if not more work on slow
architectures than you have, that's why I do a lot of cross-building.

> And that’s what I’ll be uploading to experimental later.

Sorry, that wasn't clear - you're planning on uploading old-style
debhelper packaging for pax to experimental? If yes, then thank you. Is
that upload tagged to close this bug? Use of old-style debhelper
throughout debian/rules & .install files etc. would be a suitable fix.

> Despite
> that, I state here, for the record, that I believe I am entitled
> to do this.

Entitlement doesn't mean that it's the right thing to do in all
situations. I'm entitled to upload all manner of rubbish to the archive
- or to seek the removal of all manner of rubbish already in the
archive - but I listen to my peers and contribute code which uses
methods which help my colleagues to debug not only my code but my
packaging.

> Oh, another thing that’s “wrong” with it: I wanted to build mksh on
> architectures where debhelper – or anything Perl, for that matter –

In that case, you can't use dpkg-architecture, dpkg-shlibdeps,
dpkg-gencontrol - all of which are part of your personal build system
and any packaging system based around Debian. So, what you mean is
that you want to build the upstream code and install it directly from
the Makefile - fine, no problem with that. You don't need dpkg, perl or
pax to do that.

If you do want a .deb to do that, cross-build it - at which point, ooh,
look, perl is installable just fine. Thankfully, it's not necessary to
cross-build perl to cross-build things which use perl as build tools.
See my perl-cross-debian work for more on my perl involvement.

I've done the Debian-without-perl dance - that's what Emdebian Crush
is. It can be done but it has *nothing* to do with standard Debian.
Changes for that specific situation have no place in the main Debian
archive. That's why Emdebian Crush is so out of date - it is (and was
always going to be) incompatible with standard Debian and, as such, bit
rots very, very easily. I knew that in advance, but I did it anyway and
kept the changes out of mainstream Debian.

I could have uploaded my qof package to be able to work with busybox
instead of coreutils, to not require perl at installation time and the
rest of it. I inevitably cross-built that package many dozens of times.
I fully understand the appeal of testing a forked build with a package
you know very well. I still have those changes in VCS somewhere but
there's no way anyone will get me to upload a qof package to Debian
which implements them and I would RM any such package myself.

> is not installable, in order to test my fixes to dietlibc and klibc
> on them. Yes, these are Debian-Ports architectures which I guess you,
> in the best case, don’t care about, and in the worst case, to cite
> another RT member, don’t want to see any “more Debian-Ports spam”.

I'm not a member of the release team but I do try to be reasonably
active with RC bugs and related issues during release freezes. This
is typically because I have a large amount of work to do on Emdebian
which relies on the Debian freeze being relatively smooth. So yes,
things like this get in my way and I care about fixing that.

In Emdebian, I do care about debian-ports, we support a couple or por
t architectures in Emdebian (for now at least, interest does seem to be
waning). So I do care about powerpcspe, I did what I could to help
armhf and I'll do the same for arm64 but I am getting the message that
users don't seem to care about sh*. m68k is completely irrelevant and
has been since it was dropped from Debian for not keeping up.

Don't assume things about me - I don't hide my involvement in Emdebian
and I don't claim to be part of the release team. It shouldn't be too
hard to work out what I do in Debian. I am a strong and active
supporter of / contributor to debian-ports (and debian-blends and
debian-derivatives and i18n and a range of other teams in Debian). I
don't hide any of that and I don't deserve to be denigrated by your
hasty assumptions.

> Maybe this sheds some light on my motivation.

Sadly not because I believe you are letting your personal preferences
blind you to the wider requirements and benefits of working within
Debian. I did a huge amount of stuff for Emdebian Crush which I would
never dream of inflicting on standard Debian. There are times and
places for personal preferences: limited usage builds and forks. m68k
is clearly your pet project but it has NO relevance to Debian and I say
that as someone with a clear and unequivocal commitment to the current
set of Debian ports and as an Emdebian developer who's even had some
m68k hardware once upon a time. Seriously, m68k is not relevant. Move it
into a side tree, do the same as I did for Emdebian Crush on ARMv4
and push the changes aside.

If you really want to predicate all your work on the requirements of
m68k then fork Debian and just work on m68k. Otherwise, forget m68k and
get with the rest of the project.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Message part 2 (application/pgp-signature, inline)]

Reply sent to Thorsten Glaser <tg@mirbsd.de>:
You have taken responsibility. (Mon, 26 Nov 2012 17:51:04 GMT) Full text and rfc822 format available.

Notification sent to Steve McIntyre <steve@einval.com>:
Bug acknowledged by developer. (Mon, 26 Nov 2012 17:51:04 GMT) Full text and rfc822 format available.

Message #96 received at 690381-close@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: 690381-close@bugs.debian.org
Subject: Bug#690381: fixed in pax 1:20120606-3
Date: Mon, 26 Nov 2012 17:47:45 +0000
Source: pax
Source-Version: 1:20120606-3

We believe that the bug you reported is fixed in the latest version of
pax, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 690381@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thorsten Glaser <tg@mirbsd.de> (supplier of updated pax package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Format: 1.8
Date: Mon, 26 Nov 2012 17:01:37 +0000
Source: pax
Binary: pax
Architecture: source amd64
Version: 1:20120606-3
Distribution: experimental
Urgency: low
Maintainer: Thorsten Glaser <tg@mirbsd.de>
Changed-By: Thorsten Glaser <tg@mirbsd.de>
Description: 
 pax        - Portable Archive Interchange (cpio, pax, tar)
Closes: 690381
Changes: 
 pax (1:20120606-3) experimental; urgency=low
 .
   * “Our littlest” upload
   * Policy 3.9.4.0, with no relevant changes
   * Drop temporary B-C for fakeroot on hurd again
   * debian/watch: mangle the epoch away so DDPO is green again
   * Completely rewrite packaging using debhelper (Closes: #690381)
Checksums-Sha1: 
 9e0c19f6868d241f50a39ef2e3d88b20387c7977 1773 pax_20120606-3.dsc
 c49fd618a4c7b838d602c8bccf13ec7c5f3b6fcd 6164 pax_20120606-3.debian.tar.gz
 c0222da8dcd80fe66462c312fad2c1df4165bb45 86080 pax_20120606-3_amd64.deb
Checksums-Sha256: 
 5562f6783d817c0972a96e87f67ae76bc35e71f3dce693abcaaab01a26bd90ac 1773 pax_20120606-3.dsc
 da3d2fc80e8de6b97499818479e20e2b20d2c4ac83ea05acdf59b38e880c4396 6164 pax_20120606-3.debian.tar.gz
 d88087ad8e5e7c6d853c5d0b67e366030bb0ec0b85c84d3ab31d39b2cc372339 86080 pax_20120606-3_amd64.deb
Files: 
 f9f0e58b2fabbf6ce5273cec5843d51d 1773 utils optional pax_20120606-3.dsc
 87843b2d9aabd9c59cc914805b036995 6164 utils optional pax_20120606-3.debian.tar.gz
 80feaea535ef01873039799f7ce642fb 86080 utils optional pax_20120606-3_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MirBSD)

iQIcBAEBCQAGBQJQs6lNAAoJEHa1NLLpkAfgClMP/0LheXTZWDnIx9XhrWtm0g10
/vA5WD8sbLdio9tR350i2aweeZp1FXWQ6/Knr2RIvChxyKyCTbjprVRtycUce5aB
FIZ+N9b831GK42Fqfpxxc3GmIfqr0/2ySzFJxBOs67UI2s2lz+nAH/OGu6zTLJie
jliOt3smgIuf2QYyNmDbvvDfZDilGkWPUhCnW7eSV3DBPJa+9aNqPQU4DszRVRvb
ieiPiuZxSac7SwAO5BasgBmIslCGM4M5EiL3lUIe1DqlFbRm29uX62jVxkp4O0P7
PNvVoy/YncAnbJODvno5QQHzodoQDQtAloxFNQX1rKsSceHkorwXkBmVkUw5uMOH
uOKgYMWkGItpvybyMitjcGn3cSlc+v7Jyoh7oGNiTj/MYaVnb2JeiEyVWQEaRMXe
4u4+uUVEg1M9VYPYR4GXBIh6nNhgCPVUqPX6QpZx3pvgxGVCFvzoowufHFCqXuBO
dNGxwhySL+Uv760JvSy0RmejYauOIPaYUcZ2Pc8o0CottG8/4Vr/szvcgt9vrTk3
TIPv7+xlUexnEL2WXHDMB8m0Z2ddlXMGXMAf7Gv0zsjQikjT18Q9FyNq0bGt3S0d
YaOXr16HA6tnUPWz/pXnanZqAJeZ2xmGHu6sfu1lZQWp7+IK5jDngpDIx4Ax3QYM
FRaRN1ftbyV71BrlkIwD
=tc8Z
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Mon, 26 Nov 2012 18:21:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Mon, 26 Nov 2012 18:21:04 GMT) Full text and rfc822 format available.

Message #101 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Neil Williams <codehelp@debian.org>, 690381@bugs.debian.org
Cc: steve@einval.com, debian-bugs-dist@lists.debian.org
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 18:14:06 +0000 (UTC)
Neil Williams dixit:

>m68k is not a Debian architecture

It used to be one.

>it's requirements don't matter to the rest of Debian.

So speed doesn’t matter? I’m sure the maintainers of slower
architectures that *are* still in Debian would like to disagree.
Or do you want to throw them out while here?

>Keep a fork of your code in a local repo for m68k,

There’s no need to fork anything.

>don't contaminate the rest of Debian with artificial requirements which
       ^^^^^^^^^^^
>have nothing to do with Debian release architectures.

Do you really feel like that? If so, I have nothing more to add.

>Believe it or not, I've done as much if not more work on slow
>architectures than you have, that's why I do a lot of cross-building.

And I am still of the opinion that cross-building must not be
used except for bootstrapping.

>Sorry, that wasn't clear - you're planning on uploading old-style
>debhelper packaging for pax to experimental? If yes, then thank you. Is

I do not want any “thank you” from you, TYVM. Especially after the above.

>users don't seem to care about sh*. m68k is completely irrelevant and
>has been since it was dropped from Debian for not keeping up.

The point is, there is effort to make it not completely irrelevant.
But I’m probably talking against walls here.

>hard to work out what I do in Debian. I am a strong and active
>supporter of / contributor to debian-ports (and debian-blends and

Aaaaah, sure.

Reading on… I do not want to say anything to that.



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#690381; Package pax. (Mon, 26 Nov 2012 18:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and forwarded to list. (Mon, 26 Nov 2012 18:33:03 GMT) Full text and rfc822 format available.

Message #106 received at 690381@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Neil Williams <codehelp@debian.org>, 690381@bugs.debian.org
Cc: steve@einval.com, debian-bugs-dist@lists.debian.org
Subject: Re: Bug#690381: Insane packaging of pax
Date: Mon, 26 Nov 2012 18:24:53 +0000 (UTC)
Neil Williams dixit:

>Just what is wrong with old-style debhelper like:

And in fact, it has limitations (such as not being able
to rename in dh_install) and other requirements which,
for mksh, throw a stone in my way more often than help.



Reply sent to Thorsten Glaser <tg@mirbsd.de>:
You have taken responsibility. (Mon, 26 Nov 2012 19:21:03 GMT) Full text and rfc822 format available.

Notification sent to Steve McIntyre <steve@einval.com>:
Bug acknowledged by developer. (Mon, 26 Nov 2012 19:21:04 GMT) Full text and rfc822 format available.

Message #111 received at 690381-close@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: 690381-close@bugs.debian.org
Subject: Bug#690381: fixed in mksh 40.9.20121124-2
Date: Mon, 26 Nov 2012 19:17:43 +0000
Source: mksh
Source-Version: 40.9.20121124-2

We believe that the bug you reported is fixed in the latest version of
mksh, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 690381@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Thorsten Glaser <tg@mirbsd.de> (supplier of updated mksh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Format: 1.8
Date: Mon, 26 Nov 2012 18:11:39 +0000
Source: mksh
Binary: mksh pdksh
Architecture: source all
Version: 40.9.20121124-2
Distribution: experimental
Urgency: low
Maintainer: Thorsten Glaser <tg@mirbsd.de>
Changed-By: Thorsten Glaser <tg@mirbsd.de>
Description: 
 mksh       - MirBSD Korn Shell
 pdksh      - transitional dummy package to migrate from pdksh to mksh
Closes: 690381
Changes: 
 mksh (40.9.20121124-2) experimental; urgency=low
 .
   * The “other littlest” upload
   * Redo packaging to use debhelper again (Closes: #690381)
Checksums-Sha1: 
 5161830f95c1d19a534abbb0d6133ae4070bcd07 2349 mksh_40.9.20121124-2.dsc
 c0fed713fb51e73b07eb155869a8f8c5844f7500 72511 mksh_40.9.20121124-2.debian.tar.gz
 ed0f10cb7f1657d8b2a5e1c3ac2c82139b52e7ed 2826 pdksh_40.9.20121124-2_all.deb
Checksums-Sha256: 
 64a4a8188038564bdfc5ca0c3e2d1d2dab7306bad4808ea24e59d41ed6d9601e 2349 mksh_40.9.20121124-2.dsc
 e72b8a368b4dd71c4238ec89bc570b2728d366bd46eeef52fd4c27337271c9c2 72511 mksh_40.9.20121124-2.debian.tar.gz
 55080e3f57f495b4acf92f1b6383338f4c0b7ebc29cf78e781637a5c617b04e4 2826 pdksh_40.9.20121124-2_all.deb
Files: 
 6c42811f32de603724de3039e9720c97 2349 shells optional mksh_40.9.20121124-2.dsc
 49e4fcbe72dfdd69690ed370e94d6313 72511 shells optional mksh_40.9.20121124-2.debian.tar.gz
 9a3b574a46bc5049e7557b6729b9c3d5 2826 oldlibs extra pdksh_40.9.20121124-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MirBSD)

iQIcBAEBCQAGBQJQs7xwAAoJEHa1NLLpkAfgVuMP/RsendR+VIZcMBZSr/o4YjBX
Hl6zx6egHZiPxpuK4LHtm/DQBU+UiU0eDUaxvLomGK+ea97yGhkyVlh39DnxxbZe
ccAfvirkTWGnrtiAGP5UibYdzCvv3iyav8NjoA+m1/UqYweOnZNQ4z2GPLmKZWGJ
mLrjqPX1licxPb35kS/P4zSvJWP/m6WqAjWSaX8JCu42FfOVSgDh8jyn+z/psZXX
eZFxbXAKfjtQ5FoT/AZtp60WF5TOyQ6sgISGqm+bxiyeRwMt6hOmndz8fnvDTpub
UdpLhlIrOC6Um9eOPlhG+imdOkomaFuxisfemGudN7gYo2kS39l/6qr+PcmjALdh
D3snuBEvYR0jNM+FCCMeFuzSPPcOXu3CcsUQMmiNKg9gyvjG/p54/5q5cO8pvIQV
swluaiwnhk9oOAcuiv8u4G5DZoseHWKp8+rU+D+DNVsSOOcWD/d7682YGQc+rSYJ
tHIoTAKbbpyBfbfXEyUP5u9buFtC4CxRh7ygycw1zLxjvVRF1K0XODS0YYY3JIlH
Pc7OXEUnKK8Hur40Oa38zlfvLEpENquN+ZeFvks902hYItCXNLMRFQ9ykv+jp/Je
vVS89+m0U7rpNam0OMieeryNyzlB7OjH8ZXnMm0o/awj/nFMQ3v7qqH/Jy09wLbu
88YUNjxUWYg7S7ygTEER
=QhrC
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Tue, 27 Nov 2012 11:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gergely Nagy <algernon@balabit.hu>:
Extra info received and forwarded to list. Copy sent to Thorsten Glaser <tg@mirbsd.de>. (Tue, 27 Nov 2012 11:21:03 GMT) Full text and rfc822 format available.

Message #116 received at 690381@bugs.debian.org (full text, mbox):

From: Gergely Nagy <algernon@balabit.hu>
To: 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane packaging of pax
Date: Tue, 27 Nov 2012 12:19:22 +0100
Thorsten Glaser <tg@mirbsd.de> writes:

> Neil Williams dixit:
>
>>Just what is wrong with old-style debhelper like:
>
> And in fact, it has limitations (such as not being able
> to rename in dh_install) and other requirements which,
> for mksh, throw a stone in my way more often than help.

FWIW, you do not need to use purely debhelper. For cases where it does
not support what you wisht to do, you can still fall back to good old
mv/cp. Building on dh_* is fine, but one does not need to be constrained
by its limitations, there's nothing wrong with adding a cp/mv line to
d/rules.

(I would also mention dh9+ and dh-exec, but that would probably result
in very angry thoughts aimed at my person from all parties involved here
:P)

-- 
|8]




Information forwarded to debian-bugs-dist@lists.debian.org, Thorsten Glaser <tg@mirbsd.de>:
Bug#690381; Package pax. (Thu, 25 Apr 2013 11:27:09 GMT) Full text and rfc822 format available.

Message #119 received at 690381@bugs.debian.org (full text, mbox):

From: Jakub Wilk <jwilk@debian.org>
To: 690381@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Thu, 25 Apr 2013 13:22:54 +0200
I had a look at pax (1:20120606-2+deb7u1) debian/rules. I didn't find it 
insane, or even unreadable. There's a few obscure places, and a few 
minor bugs, but that's it. Thorsten, I hope you'll find my review 
useful:

>DEB_BUILD_ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
>DEB_HOST_ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
>DEB_HOST_ARCH_OS=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
>DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

I'd use "?=" instead of "=" here. dpkg-buildpackage sets these variables 
for you, so you could avoid a few forks.

>CFLAGS=			-O$(if $(findstring noopt,${DEB_BUILD_OPTIONS}),0,2) -g

Here and in other places, I'd use "filter" instead of "findstring".

>debian/.build_stamp:
>	# goodbye dh_testdir
>	test -f tty_subs.c
>	test -x debian/rules

dh_testdir is probably the most useless debhelper command. :) I've been 
eradicating it from my packages. Instead, I use make rules to ensure 
that d/rules is run from the correct directory. Something like this 
should do the trick with less forks:

debian/.build_stamp: tty_subs.c debian/rules

>	+for opts in '-flto=jobserver' '-fwhole-program --combine' ''; do \
>		set -x; \
>		${CC} ${CPPFLAGS} ${CFLAGS} $$opts ${LDFLAGS} -o pax ar.c \
>		    ar_io.c ar_subs.c buf_subs.c cache.c cpio.c file_subs.c \
>		    ftree.c gen_subs.c getoldopt.c options.c pat_rep.c pax.c \
>		    sel_subs.c tables.c tar.c tty_subs.c; \
>		test -x pax && exit 0; \
>	done; echo >&2 Compiling failed.; exit 1

Could you perhaps put the file list in a variable? That'd make the 
command easier to read.

>	-rm -f pax

You don't need "-" (here and in other places). The -f option already 
ignores ENOENT errors, and you _don't_ want other errors ignored.

>	echo .nr g 2 | cat - cpio.1 | \
>	    gzip -n9 >debian/pax/usr/share/man/man1/paxcpio.1.gz
>	echo .nr g 2 | cat - pax.1 | \
>	    gzip -n9 >debian/pax/usr/share/man/man1/pax.1.gz
>	echo .nr g 2 | cat - tar.1 | \
>	    gzip -n9 >debian/pax/usr/share/man/man1/paxtar.1.gz

I'd use a for loop here.

>	chmod 644 $$(find debian/pax -type f)
>	chmod 755 $$(find debian/pax -type d) \
>	    debian/pax/bin/pax

I'd use "find ... -exec chmod ..." here, as it handles errors better.

>	(cd debian/pax && find . | sort | ./bin/paxcpio \
>	    -oC512 -Hustar -Minodes -Mlinks -Muidgid -Mgslash) | \
>	    gzip -n9 >debian/B/data.tar.gz
>	cd debian/B/c && chmod 644 *
>	(cd debian/B/c && find . | sort | ../../pax/bin/paxcpio \
>	    -oC512 -Hustar -Minodes -Mlinks -Muidgid -Mgslash) | \
>	    gzip -n9 >debian/B/control.tar.gz
>	echo 2.0 >debian/B/debian-binary
>	read fn rest <debian/files && cd debian/B && \
>	    ../pax/bin/paxtar -A -M dist -cf "../../../$$fn" \
>	    debian-binary control.tar.gz data.tar.gz

This is completely obscure, but I appreciate the idea of eating your own 
dog food. :)

-- 
Jakub Wilk



Information stored :
Bug#690381; Package pax. (Thu, 25 Apr 2013 12:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thorsten Glaser <tg@mirbsd.de>:
Extra info received and filed, but not forwarded. (Thu, 25 Apr 2013 12:39:05 GMT) Full text and rfc822 format available.

Message #124 received at 690381-quiet@bugs.debian.org (full text, mbox):

From: Thorsten Glaser <tg@mirbsd.de>
To: Jakub Wilk <jwilk@debian.org>, 690381-quiet@bugs.debian.org
Subject: Re: Bug#690381: Insane debian/rules
Date: Thu, 25 Apr 2013 12:27:39 +0000 (UTC)
Jakub Wilk dixit:

> I had a look at pax (1:20120606-2+deb7u1) debian/rules. I didn't find it
> insane, or even unreadable. There's a few obscure places, and a few minor bugs,
> but that's it. Thorsten, I hope you'll find my review useful:

Oh okay, thanks.

>> DEB_BUILD_ARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH)
>> DEB_HOST_ARCH=$(shell dpkg-architecture -qDEB_HOST_ARCH)
>> DEB_HOST_ARCH_OS=$(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
>> DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
>
> I'd use "?=" instead of "=" here. dpkg-buildpackage sets these variables for
> you, so you could avoid a few forks.

Hm. I’m not 100% sure I can trust these, though (until recently,
I regularily packaged and built for etch-and-up, with some sarge
builds thrown in).

>> CFLAGS=			-O$(if $(findstring
>> noopt,${DEB_BUILD_OPTIONS}),0,2) -g
>
> Here and in other places, I'd use "filter" instead of "findstring".

“findstring” was what Policy or devref used, that’s why.

> dh_testdir is probably the most useless debhelper command. :) I've been
> eradicating it from my packages. Instead, I use make rules to ensure that
> d/rules is run from the correct directory. Something like this should do the
> trick with less forks:
>
> debian/.build_stamp: tty_subs.c debian/rules

Thanks, that’s a nice one.

> Could you perhaps put the file list in a variable? That'd make the command
> easier to read.

True.

>> 	-rm -f pax
>
> You don't need "-" (here and in other places). The -f option already ignores
> ENOENT errors, and you _don't_ want other errors ignored.

Indeed.

>> 	echo .nr g 2 | cat - cpio.1 | \
>> 	    gzip -n9 >debian/pax/usr/share/man/man1/paxcpio.1.gz
>> 	echo .nr g 2 | cat - pax.1 | \
>> 	    gzip -n9 >debian/pax/usr/share/man/man1/pax.1.gz
>> 	echo .nr g 2 | cat - tar.1 | \
>> 	    gzip -n9 >debian/pax/usr/share/man/man1/paxtar.1.gz
>
> I'd use a for loop here.

The commands differ though; a for loop would need a special case
for pax(1) itself. I personally think this is easier to read.

> I'd use "find ... -exec chmod ..." here, as it handles errors better.

I never use find -exec and try to avoid find as much as possible.
That’s personal style and cautiousness, having seen people being
bitten by mistakes with find much harder than without them.

> This is completely obscure, but I appreciate the idea of eating your own dog
> food. :)

That was the idea behind it ;-)

I kept the dh_* equivalents in comments, in the hope that the
obscureness was reduced by it a bit.

But in the end… I decided fighting the Brits wasn’t worth it,
especially with being threatened to let the package be removed
from the archive.

Nevertheless, thanks for both the review and the moral support.

bye,
//mirabilos
-- 
Sorry,  I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity, like  systemd,  feminism
or social democracy.
		-- Christoph Lohmann on dev@suckless.org



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 19:39:38 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.