Review Rules and staticly linked packages agains dietlibc

[Enrico Scholz]

j.w.r.degoede at hhs.nl (Hans de Goede) writes:

> I believe this is a very clear case, upstream does _not_ advise the
> use of dietlibc, their default makefile and install instructions don't
> use it. They do give instructions on howto use it if you want, but
> they don't _advise_ it.

oh, come on. Almost none of the other packages' upstream _advises_ to
use the default RPM_OPT_FLAGS, but they are/should be used in all
packages nevertheless. Chosing the best flags and compiler is task of
the packager. And in this case, 'dietlibc' is the best choice.


> Why? Because static linking is BAD for lots of reasons,

Please tell me, why static linking is BAD in *this* case.


> many the same reasons why the packaging guidelines state that
> packages should not compile and (staticly) link against their own
> version fo system libs,

The "should" in the packaging guidelines was intentionally. It leaves
room to link statically when this is the better choice and in this case,
dietlibc is the better choice.


> that is exactly what you're doing now linking against an own version
> of system libs.

??? I do not see where 'ipvsd' links against a "local copy of a library
that exists on the system".


> is the exception that confirms the rule. Also notice:
> "Static libraries should only be included in exceptional circumstances."

'ipvsd' does not provide static libraries.


> (modern PC's are _fast_ and have _lots_ of mem),

That's a really stupid argument... when there are ways to make things
work better, these ways should be gone. Again: linking against 'dietlibc'
has only advantages for 'ipvsd'.




Enrico