On Wed, 2005-07-27 at 10:53 -0400, Christopher Aillon wrote:
> IMO, the only thing that we should be discussing now since you are so
> adamant about this whole affair is when you are going to stop ranting
> about naming schemes,
Seems as if you haven't understood what this is about :(
> and provide me with a patch to let Firefox build
> against the shared nspr libs instead of the static nspr libs, as that
> would obviate this entire discussion.
I am too long in this business to fall into this old rhetorical trick
from the "1000 tricks to get rid of customers in 1st level support" grab
bag - I am not going to solve your bugs.
But let try to outline what I have in mind:
The point I am talking about, is you to ship a package called
nspr-static instead of nspr-devel (s/devel/static/g in your specfile),
because you are shipping static libs only, and then use BR: nspr-static
inside of packages linking against this static libnspr.
E.g.
<package>
%{_bindir}/*
<package>-static
%{_includedir}/*
%{_libdir}/lib*.a
I.e. there would not be any *-devel package at this point in time,
anymore for packages shipping static libs only. Packages wanting to link
against them would be required to use <package>-static.
This is one point where the dependency on a static lib would become
explicit. And yes, this would be incompatible to now. However, this
incompatibility is intended - The purpose of this whole undertaking is
to make the dependency on a static library explicit, by mapping it to
build-time package dependencies.
When you once should be shipping a shared libnspr, you could reorganize
the packages this way:
<package>
%{_bindir}/*
%{_libdir}/*.so.*
<package>-devel
%{_includedir}/*
%{_libdir}/*.so
<package>-static
Requires: <package>-devel
%{_libdir}/*.a
If you want to drop the static lib, you would remove <package>-static,
which would cause the "BR: <package>-static" inside of apps trying to
statically link, to break. This is yet another point where the
dependency on a static lib would become explicit and intentionally break
if packaging changes.
Anyway, as Warren correctly pointed out, applying this scheme to FC
probably is an illusion :(
Ralf
