[Pkg-javascript-devel] libjs-* vs. libnode-*

Jonas Smedegaard dr at jones.dk
Fri Oct 14 00:13:30 UTC 2011


On 11-10-14 at 02:02am, Jérémy Lal wrote:
> On 14/10/2011 01:42, Jonas Smedegaard wrote:
> > On 11-10-14 at 12:02am, Jérémy Lal wrote:
> >> On 13/10/2011 23:48, David Paleino wrote:
> >>> On Thu, 13 Oct 2011 20:45:34 +0200, Jonas Smedegaard wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I just noticed that libnode-backbone-dirty depends on a mixture of 
> >>>> libjs-* and libnode-* packages.  That is correct according to 
> >>>> Debian Policy, but looks ugly.
> >>>>
> >>>> We discussed it briefly recently, where Jérémy felt that it was 
> >>>> unusual for same package to support both libjs-* and libnode-* so 
> >>>> less of an issue.
> >>>>
> >>>> Now that David has added a bunch additional packages there is 
> >>>> perhaps material for looking at this issue again?
> >>>
> >>> Given I hadn't found any policy about this, I went "by heart" about 
> >>> package naming.
> >>> I called libnode-* those libraries I thought were node-specific, and 
> >>> libjs-* those which could be of general usage (example: 
> >>> libjs-backbone).
> >>>
> >>> Still, I'm not satisfied by the approach I'm taking, and would 
> >>> prefer a more objective guideline :)
> >>
> >> I think libjs-* should be reserved for "browser libs" uses.
> > 
> >> In some cases, the choice is obvious, since the lib cannot run, or has 
> >> no use, inside a browser. Then it should be named libnode-*.
> >> There are cases where it can run on both : i'm for building two 
> >> binaries out of one source.
> >> Symlinks to the libjs-* from libnode-* may not be a good idea. It 
> >> seems simpler to just build two independent packages.
> > 
> > I agree that it generally makes sense to package separately:
> > 
> > For browsers it makes sense to aggresively merge and compress sources 
> > using uglifyjs (or yui-compressor), as bandwidth is a major factor and 
> > compressors test for _browser_ compatibility.
> > 
> > For Node it makes sense to install code snippets unmerged and 
> > uncompressed, allowing Node to deal with it directly - perhaps improving 
> > performance by tracking timestamps or location of each snippets.
> > 
> > Might be that some package really is identical for both browser and Node 
> > consumption - but that is most likely the exception, not the rule.
> > 
> > I do recall now that something along that reasoning was raised by Jérémy 
> > in the past - and that I didn't understand it.  Now I do.  So credits to 
> > Jérémy for above!
> > 
> > 
> > Someone volunteer to create a wiki page to document this?
> 
> Oh yes. I'll help, but don't let me do this !
>  
> > I suggest that we call it "Debian Javascript Policy" because browser and 
> > Node code are both subsets of Javascript.  But again I recall Jérémy 
> > arguing differently in the past.  Care to try elaborate again, Jérémy?
> 
> You could say browser and node code are just using different core environments, while
> being both javascript scripts.
> I guess that was it.

Not sure where you are going with that.

Do you agree to make one Policy that describes e.g. how to package same 
code twice if usable for both flavors of Javascript?

Or do you say that it is better to make a "Node Javascript Policy" and 
an, ahem, "Javascript Javascript Policy"?


 - 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/20111014/a6c7c7d5/attachment.pgp>


More information about the Pkg-javascript-devel mailing list