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

Re: Fwd: Bug#764549: ITP: siril -- Astronomical image processing tool

* Vincent Hourdin [2014-11-11 14:25:43 +0100]:
> - we had a special rule in autoconf to remove -g from the default '-g
>   -O2' CFLAGS. It doesn't make sense to us to have both by default,
>   since optimizing makes debugging not working properly.

It can still be handy to have the debugging information available when
interpreting a core dump or a stack trace. Normally the executables are
stripped (by dh_strip) later in the package build process. The stripped
symbols can be kept in a separate -dbg package, or in a separate file in
/usr/lib/debug/, or discarded (the default).

>                                                          Now, debuild
>   passes its own CFLAGS that contains '-g -O2' and many others. Our
>   mechanism is not able to filter out the -g in that case. May I ask if
>   this is normal to have these in debian built packages? Are all debian
>   packages built with -g? That sounds like a lot of wasted space to me.

I believe that most of them are indeed compiled with -g, then stripped.

>   I have seen there are some options like DEB_CFLAGS_MAINT_SET, but I
>   guess that's not recommended. What is the recommended way of setting
>   CFLAGS with debian packages, or of removing the -g at least?

You may want to read the dpkg-buildflags(1) man page. Something like
should do what you're asking for (but I don't remember ever seeing it in
actual use, probably because of dh_strip).

> - once we have the debian unstable package created, is there an easy way
>   to port it or to include it in other distributions, like Ubuntu, Mint
>   and other debian derivatives?

Once the package is in Debian unstable it will find its way to Ubuntu universe.
Not sure about other derivatives. In the worst case, interested users can
grab the source package from Debian, tweak it as needed, and rebuild it for
their target environment. The extent of the required tweaking can vary
depending on the package and the target environment; it isn't much different
from backporting.

Reply to: