Re: rpms/compat-guichan05/devel compat-guichan05.spec,1.1,1.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Schwendt wrote:
On Mon, 09 Apr 2007 17:28:18 -0700, Wart wrote:

Michael Schwendt wrote:
On Mon, 9 Apr 2007 14:28:53 -0400, Michael Thomas (wart) wrote:

Author: wart

Update of /cvs/extras/rpms/compat-guichan05/devel
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv11957

Modified Files:
compat-guichan05.spec Log Message:
Add missing Provides: for the package that this obsoletes.
 Obsoletes:      guichan <= 0.5.0
+Provides:       guichan = 0.5.0
Please don't. This makes a newer guichan EVR upgrade this package.
It is questionable behaviour in RPM that is covered in bugzilla.redhat.com
for a long time: https://bugzilla.redhat.com/111071
My bad. Rebuilding now. I was trying to fix a build failure in sear, which now depends on the compat-guichan05 package:

http://buildsys.fedoraproject.org/logs/fedora-development-extras/31294-sear-0.6.3-4.fc7/

I don't understand why it still tries to pull in the guichan-0.5.0 package, when it's been obsoleted by compat-guichan05, and an update to guichan-0.6.1 has already been built.

Any suggestions, or will the next push to remove guichan-0.5.0, after which I can rebuild sear?

Together with the repoclosure report this smells a lot like a packaging
mistake (which in turn causes yum to pull in the old guichan package
which also provides the needed libs and has a shorter pkg name):

Here's what's happening as best as I can tell: the compat-guichan05-devel package has a dependency on libguichan.so.0, and on compat-guichan05. libguichan.so.0 is provided by both compat-guichan05, and by the older guichan-0.5.0. When rpm is trying to satisfy the dependencies, it's first trying to satisfy the library dependency on libguichan.so.0, and it picks up guichan-0.5.0 due to the shorter name.

I would have assumed that package-based dependencies be resolved before library-based dependencies, but that doesn't appear to be happening in this case.

Maybe we just need to manually remove guichan-0.5.0 (and guichan-devel-0.5.0) from the repo to fix this problem?

--Wart

%files devel
[...]
%dir %{_libdir}/guichan-0.5
%{_libdir}/guichan-0.5/libguichan.so
%{_libdir}/guichan-0.5/libguichan_allegro.so
%{_libdir}/guichan-0.5/libguichan_glut.so
%{_libdir}/guichan-0.5/libguichan_opengl.so
%{_libdir}/guichan-0.5/libguichan_sdl.so

These look *very* much like plugin DSOs, which ought to be moved
into the main package.


--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux