On Fri, Mar 09, 2018 at 05:55:38PM +0100, Pierre-Elliott Bécue wrote:
> > This piece of code is just designed to replace @ARCHIVE_EXT@ and
> > @SIGNATURE_EXT@ by a regexp. These are never used in the remaining portions
> > of uscan.pl or mk-origtargz.pl.
> > 
> > Could you help me at seeing how these changes might introduce any issue?
> > 
> > Cheers. :)
> To be more specific, I reviewed your changes introducing these lines of code
> before applying the patch. The commit that introduced the @ARCHIVE_EXT@
> feature is
> https://salsa.debian.org/debian/devscripts/commit/8ebab1c2bfa97830ca670d6830444297910282c7

Yes, I am aware.

Please read manpage and manpage is still correct after your change.

For example, is this correct?
| =head2 HTTP site (pgpsigurlmangle)
| Here is an example for the basic single upstream tarball with the matching
| signature file in the same file path.
|   version=4
|   opts="pgpsigurlmangle=s%$%.asc%" http://example.com/release/@PACKAGE@.html \
|       files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate

For example, is this correct?
|   version=4
|   opts="pgpsigurlmangle=s%@ARCHIVE_EXT@$%.asc%,decompress" \
|       http://example.com/release/@PACKAGE@.html \
|       files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian uupdate

My memory is vague but the above cases are now broken ... that's why I
didn't add such a trivial feature addition.  I also felt over
engineering to address such a complicated case.  So I left such case to
user's manual configuration.  You are welcomed to fix all these.  It was
getting too messy to do so.  If you can refactor nicely, that's great!


Reply via email to