Bug#517637: Standard Tarball Suffixes

[Osamu Aoki]

Hi,

On Mon, Nov 09, 2015 at 05:04:48PM +0000, Barak A. Pearlmutter wrote:
...
> http://www.example.org/foo/foo@ANY_VERSION@\.@ARCHIVE_EXT@

OK.  These are good suggestions for string choices.  Upper case looks
nice.

@PACKAGE@        
@ANY_VERSION@    [-_](\d[\-+\.:\~\da-zA-Z]*)
@ARCHIVE_EXT@    (?i)\.(?:tar\.xz|tar\.bz2|tar\.gz|zip)

I take these names :-)

But allowing this needs to happen with fix to  #763071
devscripts: [uscan] allow setting download compression ordering (prefer
xz over gz) ....
 
> where @ANY_VERSION@ eats an optional initial hyphen.

This is debatable choice.  If you do, why not \. for @ARCHIVE_EXT@
In the above, I included \.  Things have to be consistent.

> I also like the idea of allowing the tarball to be given a version
> from the timestamp which is stashed in a variable,

Date taken from web site before downloading large file

> or (in some cases
> I've dealt with) allowing a snippet of shell code to extract the
> version from inside a file inside the tarball. 

and date taken from the downloaded package have different value.

The reason to use uscan is to check if files are newer or not without
really downloading it.  So if for any reason, 2nd type is needed, just
download and update package.  Then check if new tarball content match or
not.  But if we start allowing such watch file, watch file always mark
there is newer package to download for usage under --report.  That is
not desirable.

> But that's yet another
> layer of complexity, and has potential security implications...

As long as download and unpack is done by a script in uscan, I do not
see much "security implications" but it is resource drain by doing full
download just to check date,

Osamu