Re: RFS: lbzip2
On Mon, Feb 16, 2009 at 11:01 AM, ERSEK Laszlo <lacos@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
Reply to: