[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proper way to package mozilla extensions



indeed -- proper full building from source is simply necessary in such
cases

for my case -- upstream provided me with SVN information, I wrote a
nasty but nice ( :) ) wrapper script which is called by uscan if there
is a fresh .xpi available. That wrapper exports upstream SVN, wrapps
exported release into .tar.gz and feeds it to svn-upgrade which
takes care about the rest.

The only difference now in the rules - I am zipping (greesemonkey leaves
everything open which I would consider somewhat an overkill) chrome into
.jar during "install".

This way I have fully automatic upgrade procedure, proper watch file so
I could monitor my package easily, all sources are extracted in the
.orig.tar.gz -- so it is close to be the best solution

If anyone interested:
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5.orig.tar.gz
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5-1.diff.gz
http://itanix.rutgers.edu/rumba/dists/sid/perspect/source/web/imagezoom_0.2.5-1.dsc
http://itanix.rutgers.edu/rumba/dists/sid/perspect/binary-all/web/mozilla-imagezoom_0.2.5-1_all.deb


On Tue, 25 Apr 2006, Matthias Julius wrote:
> Sometimes Mozilla extensions contain other binaries.  One example that
> I know is the Html Validator extension.  And I know that because my
> AMD64 Firefox loads the i386 version of this extension.  And when I
> try to use it Firefox says it is not compatible.

> Matthias
-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]


Attachment: pgpm6yNMVTokJ.pgp
Description: PGP signature


Reply to: