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

Re: Issue with dpkg-shlibdepds



Hi Mike,

The scenario is this:

We're making a set of interface libraries for use in cross-platform application development. We want to 100% guarantee that if an application is compiled against a particular version of the library, then it's guarateed to work indefinitely with the same level of functionality. As such, we can't upgrade the libraries underneath or we risk regression. Plus this way we can break binary compatibility without issue between versions.

The other problem is that applications built against different versions can be installed at the same time, and thus different versions of the actual libraries themselves must also be installed at the same time. For this, I don't see how we can get around it with a single package name.

To cope with this, we have different names for the libraries for each version. In linux, it's easy enough to vary the so version for this purpose, but goes against the "normal" way of doing so I'm trying to come up with the easiest way of getting it to work.

The other option is to forget packaging altogether for the libraries and package them with each application instead, but it would be more work for the application developer to deal with that.

Clancy

On Mon, Aug 31, 2009 at 10:56 PM, Mike Hommey <mh@glandium.org> wrote:
On Mon, Aug 31, 2009 at 04:03:06PM -0700, Joe Smith wrote:
> Thanks Mike. Sorted that issue out. Didn't realize I'd commented out
> dh_makeshlibs =)
>
> Another issue sprung up, though. What I need to be able to do now is have
> libngi3 (0.8) and libngi3 (0.9) installed at the same time. They don't share
> any binaries that are the same.
>
> I assume this means that I actually have to make libngi3-0.9 and libngi3-0.8
> packages as separate entities? Or is there a way to make a package not
> replace itself if there's something using it?

Why would you want that, actually ? Most of the time, this is not
something you'd want. If they are compatible, you don't even need that.
If they are not compatible, then the SONAME should be changed, not the
package name.

Mike


Reply to: