On Mon, Feb 16, 2009 at 11:01 AM, ERSEK Laszlo <la...@elte.hu> wrote:
> One such thing would be the set of paths I'd to put under an "install:" > rule. This has clearly no place in Makefile.dev which is my personal > playground, or Makefile.portable, which is what it is called. (The > default Makefile, using gcc, is a concession towards the fact that most > people have gcc without an appropriate c89 wrapper.) > > I simply couldn't satisfy all conceivable users with any "install:" > target. I believe there's a world out there that doesn't conform to the > FHS, for example users with install rights only in their respective > (freely structured) home directories. Maybe someone doesn't want to > install the manual at all. I just list the files one should consider > installing, in the README. ... Perhaps autoconf/automake can help here? >> About the manual page patch, would it be possible to make the upstream >> build process configurable so that you don't need to patch in the >> path? > > As said above, I feel strongly that putting any paths into upstream is > not right. I could run sed and co. on lbzip2.1 from the Makefile, but > the strings I'd substitute in would be different for upstream and > Debian. (And not very beautiful strings.) > > Why do you ask? Is it that the fixed paths in the patch should be > configurable? If .diff.gz patched upstream lbzip2.1 to include some > magic words, would dh_installman substitute those words? OK, understandable. I'd use sed in this situation myself, so as to avoid the need to update the patch. > Please don't suggest autoconf & co as the next step! :) Woops, already did so, sorry :) >> noopt should add -O0 to the CFLAGS and nostrip is handled by dh_strip >> so you don't need to do it as long as you always make gcc put >> debugging symbols in. > > It seems awkward to me to generate debugging symbols and then strip > them. Is there a reason to include debugging symbols per default? It can > eat up a lot of disk space (and thus buffer cache) for huge projects. > Also, -O0 is gcc's default, AFAIK. > > Can you please explain the reason for these rules?(I'll accept "that's > the way we do it in Debian" too.) I created the flags stuff in > debian/rules so that the behavior matches the Policy Manual, "4.9.1 > debian/rules and DEB_BUILD_OPTIONS"; all eight variations of The reason is "that's the way we do it in Debian". The policy manual probably has a rationale. >> Why do you install all the files in /usr/share/lbzip2 ? > > You mean: > > install -t $(DESTDIR)/usr/share/lbzip2 -m 644 -p corr-perf.sh \ > malloc_trace.pl test.sh lfs.sh Fair enough. >> I'm not comfortable uploading this without a test suite being run >> during the package build process. > > You're right. But. > > If I add small test files (perhaps the ones from the upstream > bzip2-1.0.5 distribution), I'll only test a very small part of lbzip2 > (basically no lock contention etc). If such a test passes, it proves > nothing more that lbzip2 is not fatally miscompiled and that I managed > to call the libbz2 API correctly a few times. > > Large files I obviously cannot add. The user is encouraged to test with > "test.sh" on his/her own (hopefully huge) test file. "test.sh" starts > with a correctness phase. I don't want to create a false sense of > security. "corr-perf.sh" even contains ugly hacks for input draining / > output blocking (in order to give an idea, as documentation, at least), > three tiny files test almost nothing in comparison. > > Please reaffirm that you want me to add test files. Then I'll put the > ones present in the upstream bzip2 package into the .diff (as base64 > encoded files) and add the checks to the patched-in "install:" target.> Hmm, which Debian architectures do you test on? Perhaps /dev/urandom could be a good source of data. >> lintian -I -E --pedantic --show-overrides: > > The lintian in etch doesn't know -E nor --pedantic. Even > mentors.debian.net called the .deb "lintian clean". Whatever, Yeah, always run lintian in sid and build/test your packages on a sid system (chroot, vm, etc). >> P: lbzip2 source: direct-changes-in-diff-but-no-patch-system Makefile and 1 >> more > > I looked this up in "lintian-2.2.5/checks/patch-systems.desc". How do I > "keep the changes as separate patches under the control of a patch system"? Use quilt or dpatch. This isn't nessecary (P = pedantic), especially when you as upstream are also maintaining the package. >> I: lbzip2: binary-has-unneeded-section ./usr/bin/lbzip2 .comment > > Are you suggesting that "gcc -s" doesn't strip hard enough, only > dh_strip does? Okay, I inserted dh_strip between dh_installman and > dh_compress, and cleaned up the -s from LDFLAGS. Run lintian with --info to get the rationale for each complaint, or see the website: http://lintian.debian.org/tags.html > dpkg-gencontrol: warning: unknown information field `C Homepage' in > input data in general section of control info file Hmm, > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends} See http://bugs.debian.org/498666 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
