Re: package with new soname: questions about .symbols and uploading
> 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?
> 2) what are good references for building/maintaining it?
> 3) should I recreate it from scratch - or refer to the old version of
> the package?
While I am no expert on library packaging, I always thought that the
main use of the symbol file is to allow building programs that use
symbols already present in the old version, to be compiled with the new,
and still work with the former.
(Eg, if foo@LIBBAR_1.0 is used by a program, and is linked against
libbar1 1.2, it would still result in a libbar1 >= 1.0 dependency, since
it doesn't use any new symbols)
But since there's a SONAME change involved, I see no point in symbol
files, as the program will need to depend on the new version, if for
nothing else, then for the SONAME.
Thus, in this case, I'd drop the symbol file, and use dh_makeshlibs -V
instead. I don't think symbol files are of any use for libraries that
follow this versioning scheme.
--
|8]
Reply to: