giflib for fc5

[Toshio Kuratomi]

On Tue, 2005-09-20 at 05:50 -1000, Warren Togami wrote:
> Toshio Kuratomi wrote:
> > On Mon, 2005-09-19 at 13:54 -1000, Warren Togami wrote:
> > 
> >>Thanks, OK great.  It would be helpful if you could provide a proposed 
> >>.src.rpm replacement for download and peer review to this list in a way 
> >>similar to an Extras package review request.  That way folks here can 
> >>test it and suggest other improvements while we follow the process for 
> >>replacement in Fedora Core.
> >>
> >>I suppose we want both Obsoletes and Provides of the N-V-R of libungif 
> >>and also matching -devel?
> > 
> > 
> > Here's a spec file for giflib that doesn't quite work.  It's a port of
> > the libungif spec file with a few cleanups similar to what we'd do if
> > the package was moving to Fedora Extras.
> > 
> > The not quite working portion is the virtual Provides.  I think I'm
> > running squarely into the issues exposed here:
> > 
> > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00133.html
> > and explained in this post:
> > https://www.redhat.com/archives/fedora-extras-list/2005-May/msg00175.html
> > 
> > Should I try something like:
> >   %ifarch x86_64
> >   Provides: libungif.so.4()((64bit)
> >   %else
> >   Provides: libungif.so.4
> >   %endif
> > 
> > or is that too much of a hack?  Are there other archs (ppc64?) that need to be %ifarch'd?
> > 
> > -Toshio
> > 
> 
> This issue I will wait for Jeremy to decide what to do.  Two other 
> issues in your spec:
> 
> Obsoletes: libungif <= %{version}-%{release}
> Provides:  libungif <= %{version}-%{release}
> Wouldn't the new spec make more sense like this, then start Release: at 
> 4.fc5?  This way folks could rebuild this .src.rpm and unambiguously use 
> it on older dists for personal testing and have no problem upgrading in 
> the future to the FC5 version.
> 
Made these changes.  They make more sense now than when I was thinking
about it in the wee morning hours :-)

> Have you tested a build without the explicit "Provides: libungif.so.4"? 
>   What does the autoprovide do in that case?

$ rpm -qp --provides giflib-4.1.3-1.x86_64.rpm
libgif.so.4()(64bit)
libungif <= 4.1.3-1
giflib = 4.1.3-1

(Built on an x86_64)

> Also is there any good reason why we should continue shipping the
> static archive?

There's nothing special about giflib in this regard.  Is Core converting
to "no-static archives"?  If so it's fine to remove the static
libraries.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050920/6b41bee2/attachment.sig>