On Mon, 26 Nov 2012 10:21:05 +0000 (UTC) Thorsten Glaser <[email protected]> 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/
pgplgvNeHEeGP.pgp
Description: PGP signature
