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