|
|
On 7/30/05, Michael Schwendt <bugs.michael@xxxxxxx> wrote:
> This is a packaging bug, because it pollutes the list of SONAME provides
> in a dangerous way. None of these SONAMES are really installed by the
> package in a path, where installing the package would satisfy the
> dependency of a package which required one of these SONAMES. They are
> installed into a private path, not into a location where dynamic linker
> finds them. Hence they must not be "provided".
>
> I believe we've seen broken dependencies due to something like this
> before. One package I remember is OO.o in Core, which works around it by
> redefining the %__find_provides macro.
Yeah this is exactly my concern. I'm working on splitting out
subpackages for each component now. What should I redefine
%__find_provides too? Does it matter where I redefine it in the spec?
-jef
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
|
|