Johan, On Thu, Jul 14, 2011 at 11:31:04AM +0200, Johan Van de Wauw wrote: > I've packaged a new version of my library package 'libharu'. Since > upstream uses a -RELEASE type of version number, I copied this, and > this resulted in a libhpdf-2.1.0 package. > I've now updated my package to version 2.2.1. as far as I understand your comment you suggest that your upsteam doesn't understand the concept of SONAME and SOVER (as part of a stable ABI) and just puts random changes where they are not neccessary but even worse - they are complicating things. If you can confirm that the symbols file for your last version and this version match up perfectly, then the SONAME shouldn't have been bumped in the first place and instead of introducing that broken logic into Debian you might want to start educating your upstream about what an ABI is and how to come up with a stable ABI and enjoy its benefits. I know there is a number of upstreams who plain don't care about API and ABI stability and think as long as they jump about SOVER and SONAME regularily enough this is ok. They usually just haven't bothered looking up details and are quite interested once you talk to them AFAICT. Point is that with this scheme each new release will trigger a new package name for Debian including a forced (binNMU) rebuild of all subsequent packages. This is way more overhead than what should be considered good practice. IMHO it's the far superior way to have subsequent releases follow up using the same SONAME as long as the ABI is a drop-in replacement. That way you can build as many new releases using the same binary package names as will come along and all reverse depends will continue working just fine without any rebuild whatsoever. > It builds these binary packages: > libhpdf-2.2.1 - C library for generating pdf files > libhpdf-dev - C library for generating pdf files (development files) > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/l/libharu > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget http://mentors.debian.net/debian/pool/main/l/libharu/libharu_2.2.1-1.dsc > > But I still want to fix the .symbols file. However, I was not able to > find how I should do it in this case (new packagename). > Should I just generate a new file from scratch (I have not seen > incompatible api changes) or refer to the old version number for > functions which were available before. > Anyway, it's a general concern that I find little advice on how a > symbols file should actually look [1] - whether the one I made > previously was actually valid - so I was actually considering to > perhaps not include a symbols file anymore (better no file than one > which is possibly incorrect). > > So three questions: > 1) should I still have a symbols file? Yes! By all means. And eventually (depending on the development platform of your upstream) you can even try to convice your upstream to peruse this information if they're too lazy to watch over their ABI during development. > 2) what are good references for building/maintaining it? man dpkg-gensymbols and the latest emails of Michael Tautschnig on this topic covering c++ symbols too. You may also want to have a look at http://pkg-kde.alioth.debian.org/symbolfiles.html if your lib is C++. > 3) should I recreate it from scratch - or refer to the old version of > the package? If the package name is bumped, create a new one is most probably the better way than moving the old one in place and fixing it regarding the ABI changes it'll detect. > and one fourth bonus question: > One package which I'm not maintaining relies on libharu. If I upload a > new version this will need a rebuild. How is this usually handled? File a bug against release.debian.org asking for a binNMU. See http://wiki.debian.org/binNMU for more detail. Anyway, if the package name can remain constant and the ABI is compatible or completely unchanged this is the rebuilding which you will not have to take care of. ;-) -- Best regards, Kilian
Attachment:
signature.asc
Description: Digital signature