static libraries' policy: possible solution

[Jeff Spaleta]

On 11/17/05, Michael A. Peters <mpeters at mac.com> wrote:
> On Thu, 2005-11-17 at 10:01 -0500, Jeff Spaleta wrote:
>
> > I understand and accept the argument that there will be situations
> > where a developer will want to link statically in situations which run
> > counter to Extras packaging policy standards, for example in-house
> > development needs.  How much easier can rebuilding srpms locally be
> > made so that statics can be recovered sanely?
>
> If static are not split off - then the next yum update would remove
> their rpm that has the static libraries. So you'll end up with
> developers using exclude in their yum conf - which is an even bigger
> security problem than including the static .a files.
>
> OTOH if static libraries were their own package, they could be made
> available via yum - including updates. Your common user doesn't need to
> install them, only people who need to link against them would install
> them - and they would have them updated via yum when there are bugs that
> are found and patched.

I fear you have missed my point entirely. Instead of thinking about
what the current tool limitations are I'm asking is there a way to
change client side tools that makes it possible to avoid having Fedora
mirrors provide the static libs at all in any form. Notting's comment
seem sto indicate that the rel-eng tools (which we don't have access
to review publicly...cough) are too fragile to handle another tweak so
static subpackage can be treated as debuginfo are treated now on the
mirrors.  There is also the issue of hosting space on the master
server and the mirrors. Is it appopriate to require or ask mirrors to
host the static subpackages if the are of marginal benefit?

I'll restate my question.  Can the client side tools available to
developers be re-engineered or supllimented to make it possible to
rebuild the static libraries locally and keep them updated locally as
official updates come down the line. I'm not talking about what the
limitations are for existing tools.  I'm asking is it worth modifying
client tools or creating additional tools to make it easier for
developers who need statics to rebuild them locally and keep them
updated through normal means, so developers will not have to exclude
updates at all. Can tools be designed so library updates trigger local
rebuilds of static subpackages?

-jef