Orbit - Package Manager - Specification/ideas

[Johannes Pfau]

Jacob Carlborg wrote:
>On 2011-07-19 12:33, Johannes Pfau wrote:
>> Seems like rpath could indeed work in this case. I can't find much
>> documentation about it though. Debian recommends not to use it:
>> http://wiki.debian.org/RpathIssue but I'm not sure if this problem
>> applies to orbit.
>
>Won't the same problem occur if rpath isn't used? With LD_LIBRARY_PATH 
>for example.

I'm not sure about that, but using LD_LIBRARY_PATH is even more
discouraged (because it propagates to child processes)

>
>> I'd prefer installing shared libraries system wide though. The
>> soname/version approach is not that bad. Your proposed package
>> versioning scheme could even be mapped 1:1 to the soname versions. Or
>> we could use libtools versioning scheme, which is similar, ('major'
>> and 'minor' are one field, 'build' stays the same, and an additional
>> 'age' field is added)
>> http://sourceware.org/autobook/autobook/autobook_91.html
>
>I don't want to install the libraries system wide. Again your assuming 
>Linux only. It has to work on all supported platforms. At least:
>Linux, Mac OS X and Windows.

I'm not sure if we can have one perfect approach for all operating
systems. But we could just use the rpath way and see how it works out. 

>> Having read more about it, i think I have to correct my previous
>> statement: It is possible to link to specific versions with the
>> soname approach. It's maybe a little more limited (You can't say: "I
>> want to use libfoo.so.1.2.0", You can only say: "I want to use
>> libfoo 1.x.x", and the linker could end up using 1.1.0, 1.2.0 ...)
>> but it seems this should be good enough.
>
>No, I want to be able to use an exact version.
>
I agree that's a nice-to-have feature, but is it ever really necessary?
This mechanism always picks up the newest ABI compatible library
version. Why would you want to specify one version explicitly if the
newer version can be used as a 1:1 replacement?

-- 
Johannes Pfau