On Fri, Dec 16, 2016 at 1:47 AM, Jan Engelhardt
But I cannot deduce the name 'sndfile' from a compiled program.
Why would a compiled program care?
That's the whole point of the exercise: the information comes from compiled things. One reason for this is that we use proprietary libraries (e.g., Kakadu JPEG2000, or Intel Performance Primitives, or various Gig-E-Vision cameras) for which we only have a binary. And these have dependencies that we would like to include in our analysis. We do not have access to the source. (On Linux, be happy you even get a library for the transducer!)
(Also, you do not have to deduce "pkgconfig(sndfile)", because it is a known fixed string.)
In the build process, perhaps. Which is fine if you actually build the thing. But even that may not pick up all dependencies. For example, when a library is built, the link command to build the library can reference dependent libraries (of the .so type). Later, when a program links with this library, it need not specify these other dependent libraries. No reference is needed in the build process. So, relying on the build definition to tell all is no guarantee. But, looking at the resulting binary picks up everything.
It is a compromise. RPM supports installing packages sharing the same name concurrently as long as they do not conflict. But doing that is brittle to the point that you cannot rpm -U your system without collapsing same-name packages to one. So in openSUSE, unique identifiers are used for shlib packages like libncurses5 and libncurses6. ncurses actually also highlights a case: there is just one devel and one srpm, not two.
They would not have the same name. They should share the %{NAME} part, and add -devel or -src or whatever to that. The problem is that they may not share the %{NAME} part. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org