[Pkg-javascript-devel] Packaging a new jQuery plugin!

[Emilien Klein]

Hi Jonas,

2012/2/9 Jonas Smedegaard <dr at jones.dk>:
> Hi Emilien (and others),
>
> On 12-02-09 at 10:24pm, Emilien Klein wrote:
>> Short version: I would like to get the Lazy Load Plugin for jQuery [0]
>> packaged in Debian. What's the way to go?
>
> Join our team and let us work on it together! :-)
>
>
> Or work on your own, if you prefer - just make sure to follow Policy:
> http://wiki.debian.org/Javascript/Policy

OK, seems like a good idea. I've already joined the mailing list, what
other steps do I need to take to join? I am [not yet] a DM or DD, I've
started about a year ago packaging 1 piece of code, and am now
involving myself more with Debian packaging. Is that a problem to join
the team, or should I first wait to be a D[M/D]?

>> I see that you maintain the jquery* family of packages in Debian. How
>> can I help to package Lazy Load for Debian? Should I file an ITP and
>> list you and myself as maintainers? I guess I'm basically asking how
>> your packaging team works...
>
> Our procedures are here: http://wiki.debian.org/Javascript
>
> In other words: We have few common rules of working together.

So first question about the policy: regarding the name of the source
package, should it be

jquerylazyload.js
or
jquery-lazyload.js
or just
lazyload.js

It is a jQuery plugin, so I'd think the jquery (with or without dash?)
variant is more relevant, but you tell me ;)

For the binary package, I'll prepend "libjs-" to the name of the
source package and remove the ".js".

> Personally I use CDBS for all my packages.  If you are fine with that,
> I'd be happy to co-maintain that jquery plugin with you, and other
> packages as well.  Others in this team use short-form dh so if you
> prefer that you can probably convince them to work with you.

I've started with dh for my other packages, and would prefer to
continue on that route ;)

>> Lazy Load is hosted on GitHub [2] and doesn't releases tarballs [3],
>> but the content of the git repo is available as a tarball [4] (with
>> version number) from GitHub.
>
> Yeah, Github is weird.  Sometimes tarball releases appear there and
> sometimes not.  Apparently there have been some "releases":
> http://githubredir.debian.net/github/tuupola/jquery_lazyload

Oh yeah, I remember having read about the githubredir. Handy!

> If those are lacking too much behind, then github also provides a URL
> for dynamically generating a tarball of the HEAD of the git.  I use that
> trick for e.g. json-js - but beware that then you cannot use watch files
> to track newer releases but need to watch progress "by hand".

It lists the last 3 versions, so I'll start using the redir, but still
keep an eye on the repo to see if the releases are properly published.

>> Both the source file as the "compiled" minified file are versioned,
>> and the Makefile that's included doesn't seem to be reusable. I would
>> think about just using debian/install to list both the full and
>> minified files in the resulting debian package.
>
> That's wrong approach: You should use only _source_ from upstream to
> generate binary packages.  So ignore the minified file(s) and regenerate
> using uglifyjs (or, if you prefer, yui-compressor).

OK. I guess I can take some inspiration on the jquery/-ui packages.

> Most often the process is so simple that an upstream Makefile can be
> ignored and the steps written directly in debian/rules.

Yep, I've figured that out.

>> Also, the git repo not only contains the source files, but also all
>> kinds of test html pages. Are those supposed to be present in the
>> Debian package or not?
>
> Tests possible to run automated should preferrably be included in the
> build routines.  Typically that's not the case for JavaScript, however.
>
> If you judge the html pages relevant for a user to read to help
> developing/using the JavaScript library, then include it (e.g. as
> example files below /usr/share/doc/$package/examples).

It seems to be example files, so I might include them. I'll contact
the developer to ask under which license the images are/where the
pictures come from, but it seems to me that those are "home-made".

> If relevant only for extreme purposes (e.g. speed or coverage tests),
> then just skip them.
>
>
> NB! I've set reply-to to the list only.  Please consider subscribing to
> our list and do your JavaScript packaging under our umbrella :-)

Did the list thing.

> Hope that helps,

Sure! Thanks for your fast answer.

   +Emilien