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

Re: Rationale for Policy 8.4



Nikolaus Rath <Nikolaus@rath.org> writes:
> Simon McVittie <smcv@debian.org> writes:

>> The thing to do would be to pick up the SONAME at compile time, and use
>> that as the thing you dlopen(). Alternatively, assuming the
>> Python-related code is an optional part, you could split out the
>> Python-related code into a plugin, link that plugin against
>> libpython2.6 in the normal shared-library way, and dlopen the plugin
>> (which is what I'd personally do); if libpython2.6 is missing, the
>> dlopen will fail and your application will carry on without its
>> optional Python support.

> Ah, I see. But as you already pointed out, in this case the situation is
> a little bit odd:

> The application only calls a single function from libpython2.6 which
> takes a string as its only argument. So there really is no need to
> actually compile/link against it, this would just introduce an
> artificial dependency on the ABI that is not truly there (if the
> parameter type changed from string to something else, the semantics
> would break as well and a recompile wouldn't fix it).

That's exactly the information that the ABI is capturing.  That dependency
isn't artificial at all.  If the ABI change involves a change to that
function, then indeed the ABI restriction is achieving precisely what it
is supposed to achieve.  Note that, in the presence of an ABI change that
affects that function, the current configuration of your application will
cause it to break, whereas if the application loaded the ABI-versioned
library, it would not break; it would just have a dependency on the old
library, like any other program linked against the old ABI.  This is what
Policy is designed to support.

> I guess there is no proper way to solve this, right? Either I introduce
> the artificial dependency or I need -dev to run the application?

I believe loading the versioned library is the correct solution short of
reworking the application along the lines that Simon describes.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: