Hi,
On 04/29/2012 05:13 PM, Panu Matilainen wrote:
On 04/27/2012 07:36 PM, Toshio Kuratomi wrote:
> On Fri, Apr 27, 2012 at 11:13:47AM +0300, Panu Matilainen wrote:
>>
>> I'm going to add a switch to allow packages to control the behavior
>> anyway. Whether rpm upstream defaults to the traditional behavior for
>> compatibility reasons or not is another question, but Fedora is
>> obviously free to override that. Given the packaging guideline
>> mandate to eliminate private soname provides from packages it seems
>> like a no-brainer to disable faked sonames by default, and require
>> the handful of special cases to work around it (adding
>> enable-switches to specs) instead of adding disable-switches to
>> possibly hundreds of packages to cater for the special cases needs.
>>
>> Thoughts? This would obviously only change in rawhide.
>>
>> Oh and of course eliminating the faked soname provides does not
>> eliminate all unwanted provides, eg libtool adds a soname even when
>> -module is used. But ... you need to start someplace.
>>
> Will the toggle to turn it on and off work for those libtool generated
> modules (as long as there's not public libraries in the same package)? Is
> it possible to turn this on and off per subpackage or is that along the
> lines of asking for pretty pink ponies with wings?
For now, I'm only talking about a switch that stops faking a soname provide when an
ELF DSO does not provide one, nothing more. Also that switch is going to be a global macro
to avoid spec syntax compatibility issues, at least for now.
As for the other issues like libtool generated modules, the question is: why does libtool
insist on creating a soname for them, and could we get libtool changed not to do that?
Also it might be possible to come up with heuristics to detect (some of) such modules
based on the data in elf headers.
If we go the heuristics way, why not do heuristics based on the location of the
library? If the .so sits directly in a standard libdir it is likely something
other packages can depend on / link against. If it sits in a subdir it is likely
not. You can extend this heuristic by adding dirs found in
$RPM_BUILD_ROOT/etc/ld.so.conf.d/*.conf
to the standard libdirs before running this heuristic. This should give a
pretty good score both wrt filtering out unwanted provides as well as
not having any false positives.
Regards,
Hans