Re: Eliminating automatic provides on private libs

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

 



On 04/29/2012 06:25 PM, Panu Matilainen wrote:
On 04/29/2012 06: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.

Actually... one painfully simple and obvious heuristic is the DSO
basename: if it doesn't start with "lib", it's almost certainly not a
regular library.

...but then there's ld-*.so. Which of course is not your average regular library either, but requiring spec tweaks to get the necessary provides into place for such a fundamental piece of the system doesn't seem right either.

One possibility that looks like it should weed out nearly all the private libs (plugins etc) whether created with libtool or not, and still handle ld-linux.so correctly by default:

Only create soname provides if the DSO specificies specifies a SONAME, and the soname either starts with "lib" or is versioned.

It's just that it's getting a bit thick in the heuristics department. Sigh... it would all be sooooo simple if presence of SONAME could be used as a mostly reliable indicator for the DSO's public/private status :(

	- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[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