[Pkg-osg-devel] Package improvement (was: 3.0.1-2 upload)

[Alberto Luaces]

"Manuel A. Fernandez Montecelo" writes:

> 2012/1/8 Alberto Luaces <aluaces at udc.es>:
>> Loic Dachary writes:
>>> I can upload, sorry for the lag. I just started a new job and I
>>> overlooked your call for action. However, I would be gratefull if you
>>> can upload instead of me because that will save me a little time. Just
>>> let me know.
>>
>> Hey guys,
>>
>> thanks a lot for helping me. Manuel, yes it's completely right that you
>> sign the release. I should have left the changelog open in the first
>> place.
>
> I will do unless I have some problem, in which case I will let you
> know.  Otherwise you'll notice by the automatic emails :-)
>

Thanks! It seems it's working!

>
> 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.

* 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?

* 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?

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 :)

Regards, 

-- 
Alberto