Review Rules and staticly linked packages agains dietlibc

[Patrice Dumas]

> an Bug #176579 I have a review, where soneone will published a
> package with programs which are staticly linked agains the
> dietlibc.
> 
> Becouse I'm unsure about the packaging guidelines I want hear the
> mind of other contributors on the list.

It seems to be aginst the packaging guidelines. However it is a very
specific case where static linking is advocated for speed reasons. If
I am not wrong, the reasons to link dynamically because of the 
implementation of some glibc functions doesn't hold. However the security
issue is still there. So, in that precise case, the choice is between 
security and efficiency. 

I see 2 possibilities

1) add a benchmark to the review (speed measurement for both cases, and 
   memory footprint) that demonstrates a clear win with static libs.
or
2) make two packages or 2 executables in the same package, one with the
   static and the other with the shared, and give the original name
   to the shared, and call the other by a name that helps understand
   that it is statically compiled.

In any case if in the end there is something statically linked it should 
be advertised in the installed files (in a README or anywhere else).

--
Pat