rpms/libsigsegv/FC-4 .cvsignore, 1.2, 1.3 libsigsegv.spec, 1.5, 1.6 sources, 1.2, 1.3

Ralf Corsepius rc040203 at freenet.de
Fri Oct 7 14:34:14 UTC 2005


On Fri, 2005-10-07 at 07:20 -0500, Rex Dieter wrote:
> Ralf Corsepius wrote:
> > On Thu, 2005-10-06 at 14:24 -0400, Rex Dieter wrote:
> > 
> >>Author: rdieter
> >>
> >>Update of /cvs/extras/rpms/libsigsegv/FC-4
> 
> >>+rm -f $RPM_BUILD_ROOT%{_libdir}/lib*.la
> >>+
> > 
> >  
> > You can't remove *.la from a package which already has been released.
> > This breaks all packages depending on this library. You can only do this
> > for unreleased packages, but not for already released packages.
> 
> I think you're being a bit overly dramatic.
No. If a package ships an *.la's these are part of these packages' API.
RH is ill-advised in removing them and so is FE.

>   It certainly does not break 
> *all* packages.  At most, it breaks only packages built that themselves 
> include libtool archives that refer to the now-missing libsigsegv.la, 
> and I'm aware of none that do.  Now, if it turns out this change *does* 
> cause problems with another FE package,
> 1.  I'd consider reverting the change, but I'd prefer that:
> 2.  The now-broken package be rebuilt against the newer (IMO 
> fixed/better) libsigsegv.
> 
> >> %check || :
> > Cosmetic issue: The "|| :" is superfluous.
> 
> It's not superfluous for those of us interested in making packages that 
> build on older fc/rh releases.  (-:
This is FE, currently addressing FC3, FC4 and rawhide, older RHs are
irrelevant.

> >> %files devel
> >> %defattr(-,root,root)
> >> %{_libdir}/lib*.so
> >>-%{_libdir}/lib*.*a
> >>+%{_libdir}/lib*.a
> > 
> > Adding a static library to a package that previous had not contained
> > one? Where is the sense in this? 
> 
> As I noted in the cvs commit log, in this case
> 1.  the static lib is *very* small (~4k)
> 2.  it doesn't depend on any external library
> 3.  I can think of cases where one may want to link statically (in 
> clisp, for instance).
1. I guess you are aware, about the general maintenance issues and
security risks shipping static libs imply?
2. If a package requires to be linked statically, it is broken by
design.

Ralf





More information about the fedora-extras-list mailing list