Bug#751984: devscripts: mk-origtargz do not handle xpi files correctly

[Osamu Aoki]

control: tags -1 moreinfo

Hi,

Can we discuss this bug?  
    https://bugs.debian.org/751984

Benjamin wrote this xpi-repack.  So I guess you know best :-)

I understand uscan does not run as it used to be with xpi-repack as the
last argument in the watch file.

I can fix situation as proposed by skipping zip repackage for xpi file.
That is easy but this create major inconsistency with the typical
package updating practice.  But this approach blocks to use uupdate.

As I see xpi-repack code, it does not do much.  Why not use standard zip
repackage and standard orig.tar.gz changes path.  What is the issue by
packaging this way.

Before discussing, can any of you point out an example I can test?

I do not see the profileswitcher package used as the example.

As I checked the libjchart2d-java package, these zip upstream have
internal xml file holding the official full version string (3.2.2) too.
But upstream zip file name also have the official full version string
(3.2.2).  So we can use it.  Does *.xpi packages must use internal xml
to get version.  As I look at some xpi files, their filenames are nicely
versioned.

If adding a stem directory like <package>-<version>/ to the repackaged
tarball of the zip contents is required, it will be nice to add such
feature for all zip archive handling cases.

Then that option can be made accessible from opts= argument of uscan.

If there are some xpi specific thing needed, we can call xpi-repack from
mk-origtargz.  Then uup\date can be used as normal case.

Please let us know what exactly required.

Osamu