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 [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
