.so's in devel packages...

[Adam Williamson]

On Tue, 2012-06-19 at 09:50 +0200, Michael Schwendt wrote:
> On Mon, 18 Jun 2012 12:25:12 -0700, Adam Williamson wrote:
> 
> > On Mon, 2012-06-18 at 18:23 +0100, Nelson Marques wrote:
> > > Hi all,
> > > 
> > > 
> > > I have a doubt regarding the '.so's' in devel packages... From my
> > > understanding they go in devel packages to allow the installation of
> > > several packages with different versioning....
> > 
> > Not really, no. They go in -devel packages because the only time it's
> > actually appropriate to use a library by referring to its unversioned
> > name is when you're compiling another application against it. It's never
> > safe for anything to access a library at runtime via an unversioned name
> > because there is no guarantee of stability; you can't be at all sure
> > that the version of the library you're calling is actually capable of
> > doing what you're asking it to do. Since the only use of the unversioned
> > 'instance' (symlink, in Fedora...) of a library is in development,
> > naturally it goes in the devel package. We can take advantage of this in
> > generating dependencies, and we do, which is why it's important not to
> > put the .so file in a runtime package, or that runtime package will get
> > a bunch of automatically generated dependencies on -devel packages.
> 
> And again, this is not the full story. 

I was trying to keep it simple.

> There is no hard rule on where 
> non-versioned .so files are to be packaged. They could still be local libs
> (with no API for public consumption) strictly required by an application.

I tend to talk about these as 'plugins', myself, to keep them distinct.
They're really _not_ shared libraries, in my worldview anyway - as you
say, they present no public API, they're not intended to be used by
anything else. They just happen to use the same file format. In the
context of the question - which was about .so's which _are_ in -devel
packages - it was clear the OP was asking about true shared libraries,
not private plugins.

> They could still be plug-ins, libraries loaded by an application at
> run-time. They could even be symlinks to versioned plug-in libs, with
> the application strictly requiring the non-versioned symlink when trying
> to link with a plug-in at run-time. 
> 
> Where .so files are to be put solely depends on their purpose. Many
> non-versioned libfoo.so files are just the symlink that make -lfoo work
> during compilation/linking. But that is not sufficient to require *all*
> non-versioned .so files to be placed in -devel packages.

Indeed.

> If Fedora Packaging Guidelines are still not clear about this, we may need
> another update for them. But detailed feedback on them would be appreciated
> first, IMHO.

I think the guidelines assume a baseline level of knowledge about
library versioning, which probably isn't a terrible thing, but maybe a
reference or two would help.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net