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! Osamu
