[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:


> dpkg-gencontrol: warning: unknown information field `C Homepage' in
> input data in general section of control info file


> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}

See http://bugs.debian.org/498666



Reply to: