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 <m...@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 via email to