Delayed again since I start to be overloaded again after Christmas... :-(

I will treat some topics quickly or not in-depth because I don't know
much about that...

2012/1/10 Alberto Luaces <>:
>> BTW, maybe it would be a good idea to make the package multi-arch
>> ready, build-hardened and other goodies of newer debhelper, like very
>> shortened and high signal-to-noise ratio debian/rules.  I have some
>> practice with SDL packages, OGRE and others... but maybe you prefer to
>> investigate this yourselves, for learning how to do it?
> Good ideas!
> * multi-arch ready: I think I have read something somewhere and it
>  seemed almost easy. I have put it in the TODO list in other to not
>  forget it again.

You can use this as a reference (both at the same time):;a=commitdiff;h=8999362be044a0196f9443a4fcb9c93db5da8edc;a=commitdiff;h=540916d4ee29bc19e41c71d0fa05a0d12c129373

Or possibly more clearly (also together):;a=commitdiff;h=d17cc32d9fd9f49d050b64fbad17ae5625cc1dc3;a=commitdiff;h=78cbf2990c75b4089ee1f8ca2414ffbde98762c4;a=commitdiff;h=713da62e5ff78d62120d6c6ebb22664c0468b078

> * build-hardened: I don't know what is this very well. Does it depend on
>  those special flags that you can use with gcc in order to check buffer
>  over/underruns and things like that? Is there any document for
>  starters?

Yep, that's it.  The best documents that I know:

And a quick introduction:

The first link of git above shows how to do it with debhelper compat
v9: just doing nothing else.  Exporting DEB_CFLAGS_MAINT_APPEND and
DEB_LDFLAGS_MAINT_APPEND is optional, the first are preferences of
mine and the second were used previously in sdl-mixer.

> * very shortened and high signal-to-noise ratio debian/rules: this is
>  something that bugs me, too. While converting to the new 3.0 format, I
>  was proud to separate the architecture-independent build from the
>  dependent one, so now we don't have to wait for doxygen to finish
>  doing its mono core duties at the end of the build. However, given our
>  not so simple situation —where we have to compile twice the code with
>  two different configurations (static, dynamic)— I couldn't imagine any
>  other way that exploding the build rule and almost duplicate it.
>  I would be very interested in shortening the file and stripping it
>  down to 100 lines or less, as some other packages do. Other annoying
>  thing is that the build now virtually breaks ccache, since the
>  precomputed headers for the static build are different to the dynamic
>  ones, so the caches are never reused.
> In the experimental dev/3.1.0SVN branch I have tried to implement debug
> packages, since they are very useful for understanding how OSG works
> through debugging. Unfortunately, I realized that the dbg packages can't
> be used for debugging unless you have the also the source, so unless I'm
> mistaken, they are only useful for getting backtraces. Very expensive
> backtraces, I'd say, since dbg packages are large, usually hundreds of
> megs. However, I have seen that it's the trend because a lot of packages
> are shipping its debug counterparts. Am I missing something?

I cannot now look at what can be done to OSG, you've done a nice
engineering work that maybe I will copy for OGRE with the static and
non static thing.  But I'll show you a couple of examples why I think
that it pays to convert...


Or the even more minimal package (with cmake):

One of the nice things is to not have to take care of the ordering (or
possibly missing) dh_* commands, and that it's terribly clean, so it's
very easy to spot and understand exactly what differs from a standard
package compilation & installation.

One of the things that made things difficult to package for newcomers
to Debian packagers (at least I was terribly baffled in the beginning)
is that, while 80% of the software is "./configure --flags && make &&
sudo make install" (or analog for cmake), the number of strange
incantations that one had to do to compose a minimally working
debian/rules was quite large.  Not so much now :-)

I'm sure that you'll still have to duplicate stuff and so on, but the
rest will be much cleaner.  Anyway, it's not that the final binaries
are going to be better or anything, so no need to do it or to do it
now if there are more pressing issues.

I don't know much about the modern debugging thing either, I am having
the same trouble with OGRE in Ubuntu:

It might have something to do with multiarch too, so since OGRE and
OSG are somewhat packages of the same nature, it's something to take
into account...

> Manuel, if you ever find what they call a «low-hanging fruit» and you
> want to implement it, please do. I will be delighted to learn from you
> as well :)

Well, since it's maybe your only package at the moment, I think that
it's better if I provide pointers and you learn by getting more
implicated than just looking at how it happens.  I am glad to have
tease you successfully so now you want to do it :-)

Also because Loic knows more historically about the package, and
you've been doing more of OSG work lately, so both of you are more
intimate with OSG than I am.


Pkg-osg-devel mailing list

Reply via email to