Re: proper way to package mozilla extensions
On Mon, 24 Apr 2006, Yaroslav Halchenko wrote:
> I am upgrading to the recent upstream one of the extensions I am
> maintaining. Finally I made a proper debian/watch file but now I need to
> decide which way to go on how to keep .orig.tar.gz. I've investigated a
> few packaged extensions and didn't find an answer to my question: how to
> perform automatic upgrade (via uscan). The reason is that
>
> 1. There are two possible packaging schemes
> a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it
> at build time.
>
> b. Keep unzipped .xpi in .orig.tar.gz.
c. Distribute the actual source code in the orig.tar.gz.
No; please distribute the actual upstream source, and build the .xpi.
[Hint: this isn't the unpacked xpi either... it's probably whatever
upstream has in their VCS.]
Otherwise it's a PITA to actually patch the .xpi, as you have to
unpack it, unpack the jar, patch the jar, pack the jar, pack the xpi.
Most packages don't have rules files that do this, so it means that
any security patch is going to have to go mucking about in your
debian/rules to implement this packing/unpacking and then actually add
the patch itself. Save everyone's sanity, and actually distribute the
real upstream source in the orig.tar.gz, not the "binary" package that
upstream distributes.[1]
See Michael Spang's work on greasemonkey for an example on how to do
this.
Don Armstrong
1: Note that I personally won't sponsor mozilla modules that don't
distribute the actual source in the orig.tar.gz...
--
If it jams, force it. If it breaks, it needed replacing anyway.
-- Lowery's Law
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: