So you don't want to provide the virtual package because packages which
depend on it will likely break? I know in at least one case the portion
of the API that my package used worked with multiple versions of libv8 but
the package naming issue forced my users to install libv8 manually.
Actually, what I really need to do is get my source package into the
Debian system. I have a fairly popular and mature Open-Source project but
I've been overwhelmed by the Debian package submission process and still
don't fully grock it.
On Sat, November 22, 2014 2:59 pm, Jérémy Lal wrote:
> Le samedi 22 novembre 2014 Ã 13:26 -0800, Joseph Coffland a Ã©crit :
>> ../.. The problem
>> stems from the fact that libv8 includes the library version in the
>> name not just in the package name. I know this has become common (boost
>> does too) but it's a PITA for packages which depend on such packages.
> Actually there's a reasonable explanation for that fact :
> upstream libv8 doesn't care about API compatibility between versions,
> even patch-level updates can break API.
> Even when API compatibility matches their version numbers, ABI
> compatibility is not something upstream tries to ensure. Note that it is
> more difficult to achieve with C++ libs than with C libs.
> Like Boost indeed, programs depending on a given version will often
> require patches to be able to be built on a later minor update, and must
> all be rebuilt in any case (because of potential ABI incompatibilities).
> This is a PITA - not only for debian - for all other programs depending
> on libv8 and that mostly explain also why nodejs 0.10 branch was stuck
> with libv8-3.14.
> I hope that (kind of) rant gives you a clearer view of the situation.
Cauldron Development LLC