Please CC-me, I'm not suscribed to mentors. Andreas Tille wrote: [snip] > Thanks for the hint but I admit I'm not fully sure what exactly needs to > be done to get the changed SONAME in the case of dcmtk. I guess I need > to tweak the cmake files somehow - but how?
I always promised myself to write I guide from what I have learnt from the Qt/KDE team all this years and I'm failing so far. But allow me some general rules (will possibly include more data than what you requested). And please please please *note they are general*, some people might do things differently. First some basics: - A src:library foo could be versioned a.b.c and have it's SONAME be libfoo.x, with x !=a. Normally this is not the case, but there is actually no problems with this. - Let's say the library builds libfoo.x.y.z, where: x: major version y: minor version z: patch version - If your upstream breaks API/ABI on each patch version just avoid packaging it. Or be prepared to suffer. Now let's say we have a binary package libfoo1 (from now on, bin:libfoo1) which produces libfoo1.2.3.so with SONAME libfoo1. On version 1.3.1 upstream breaks binary compatibility or API. First thing to do here: - Teach upstream why [s]he should not break API/ABI - Try to produce a patch to solve the issue. If that's not possible, then you have basically two options: - If the package just breaks ABI rename the package to bin:libfoo1abi1 and go ahead with a transition. Bonus points if you change SONAME to be libfoo1abi1 too, but that's not entirely needed, although a nice thing to do. - If the package breaks API you should really change SONAME to libfoo1.3 and package to vin:libfoo1.3. You will need to handle a much worst transition as the rdeps will need code changes. And be prepared to that on every monor update... Please be sure to understand that this is just the tip of the iceberg, and that's why we don't recommend packager newcomers to package libs: they can be very tricky. FWIW I have learned the basics of API/ABI breaking before becoming a DD and how to properly handle them after I become one and thanks to the precious help from my Qt/KDE teammates at the time. And I still have *lots* to learn. Again, i should write all this + symbols managing in some kind of doc :-/ Hope that helps at least a little. Lisandro. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
