[Pkg-javascript-devel] Review of libv8-i18n

[Jérémy Lal]

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~)".

Done.
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 :
http://lists.debian.org/debian-devel/2012/01/msg00671.html
the conclusion (faster to read) at :
http://www.eyrie.org/~eagle/journal/2012-02/001.html

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.

Jérémy.