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