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

[Jonas Smedegaard]

On 12-04-01 at 03:06pm, Jérémy Lal wrote:
> On 31/03/2012 03:18, Jonas Smedegaard wrote:
> > Seems irrelevant to me to mention origin or reverse dependencies in 
> > long description: I suggest dropping 2nd paragraph.
> > 
> > Makes more sense to me to first introduce what libv8 is and then 
> > that this package is an extension to it: I suggest swapping those 
> > two paragraphs in long description.
> 
> OK.
> I was trying to explain that libv8-i18n is mainly needed by chromium, 
> do you think it's still important to mention it ?

IMO no: what packages _use_ a library is more reliably reflected by 
package dependencies, and what _caused_ the existence of a library is 
better reflected in changelog or README, if at all relevant.


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



> > 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.


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


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20120401/dbe968c0/attachment.pgp>