On 01/04/2012 17:57, Jonas Smedegaard wrote:
> On 12-04-01 at 03:06pm, Jérémy Lal wrote:
>> On 31/03/2012 03:18, Jonas Smedegaard wrote:
>>> I recommend using d-shlibs to handle installation of library
>>> files and resolve library-related dependencies.
>> All right - i'm not sure it's properly setup now.
> Commit cae650 says "Use d-shlibs." yet involves...
> * auto-updated control* files, dropping some build-dependencies, *
> re-sorting and new-line delimiting package relations, * changes to
> auto-expanded package relations, * moving from declaring in install.*
> files to using rules file, * changing and expolicitly setting
> $soname, * generalizing $libname.
> That is quite difficult to follow. Please commit semantically
> separate changes separately, and manual changes separately from
> automated ones.
> Better if you ease backportability by relaxing build-dependency
> slightly e.g. on "d-shlibs (>= 0.51~)".
Are there cases one wouldn't want to append ~ ?
>>> Did you consider using symbols file to track API/ABI changes
>>> instead of simply relying on upstream version for that?
>>> Especially since you really do not use upstream releases but VCS
>>> snapshots: Seems unlikely to me that SONAME should be bumped
>>> exactly when upstream bumps version number, rather than such
>>> changes appearing at some earlier VCS commit.
>> After our discussion on #debian-js : libv8-i18n doesn't have
>> upstream version nor upstream soname. Choosing for upstream version
>> : 0~0.svn7 Choosing for soname : 0.0.0 Library version :
>> $(soname).0.0 Hence full lib version will be 0.0.0.0.0
> Well, my point about symbols file is related but different:
> You write in a comment in rules file that SONAME "Most likely will
> change with each update." Using symbols file it can be tracked if in
> fact upstream changed the ABI or not.
I forgot to mention :
the conclusion (faster to read) at :
And it's true that the generated symbols from libv8-i18n will
ask for a lot of work that is not going to be useful.
To get the list of symbols :
dpkg-gensymbols -plibv8-i18n0.0.0 -Pdebian/libv8-i18n0.0.0
>>> Would be good if you could have get-orig-source target include a
>>> rule to generate a Changelog.svn file, e.g. using
>>> /usr/share/doc/subversion/examples/gnuify-changelog.pl.gz (but
>>> since it is forbidden to rely on /usr/share/doc to exist, that
>>> script should then be included in debian/ subdir).
>> Great. I took the upstream copy - relicensed under Apache-2.
> When you grab something from Subversion (i.e. that
> gnuify-changelog.pl script), then mention which commit (in copyright
> file Comment field). Also, it might be better to use svn2cl from
> subversion-tools package (you need not build-depend on that package,
> just add an informative error message, as get-orig-source is an
> optional build target).
Done, and debian/copyright* reset accordingly.