Re: [Pkg-javascript-devel] Review of libv8-i18n
On 31/03/2012 03:18, Jonas Smedegaard wrote: Hi (mostly) Jérémy, You asked me on IRC to review libv8-i18n, and I now found time to do so: Copyright file lacks Upstream-Source URL(s) and Upstream-Contact address(es). Source field. Done. Copyright file lacks a Comment: referencing actual Apache 2.0 license below /usr/share/common-licenses. Done. Patch 2002 changes to include v8.h - but if that's system shared header I suspect that should instead be v8.h. Done. 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 ? Please use anonvcs.debian.org URL in Vcs-Browser field. anonscm.debian.org Done. 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. I suggest re-wrapping control file long descriptions and copyright file License fields at 72 chars (not 80 chars). Done. And favorite editor configured once and for all so that won't happen again :) 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 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. Jérémy. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Review of libv8-i18n
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 signature.asc Description: Digital signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Review of libv8-i18n
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. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Review of libv8-i18n
On 12-04-01 at 07:45pm, Jérémy Lal wrote: 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: 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 ~ ? Yes, you should apply common sense. Example: libv8-dev (= 3.8) refers to an upstream version which won't be lowered in a (sane) backport. 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 I am aware of that thread. That thread does not convince me, however, that it is irrelevant to try. Did you try, or do you consider it not worth the effort to try? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Review of libv8-i18n
On 01/04/2012 20:09, Jonas Smedegaard wrote: On 12-04-01 at 07:45pm, Jérémy Lal wrote: 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: 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 I am aware of that thread. That thread does not convince me, however, that it is irrelevant to try. Did you try, or do you consider it not worth the effort to try? At first : not worth the effort. I had a look in the future when revision 32 will be needed for chromium 19 : no changes in symbols -- no apparent soname change needed. So you're right. (and i pushed the symbols file). But the javascript api changes, and since software using libv8-i18n will also rely on that js interface... Jérémy. ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
