Bug#748474: clean-orig-sorce target (custom download scripts)

[Nicholas Bamber]

Osamu,
	with the get-orig-source I think I really messed up my explanation of 
how I see things.

	Once a maintainer has dtermined  that the upstream download method is 
too whacky to expect uscan to cope, and has to resort to a 
get-orig-source target in the debian/rules file, then yes uscan is out 
of the picture for downloading the tarball.

	However uscan is also used in say the DDPO reports to identify when a 
new version is available. That function of uscan cannot be handled by 
debian/rules but uscan could offer a wrapper around the get-orig-source 
target to make that infomration available via the debian/watch interface.

	Does that make my point clearer?

On 07/12/15 13:13, Osamu Aoki wrote:
> Please respond to 748474 at bugs.debian.org
> Please drop       458789 at bugs.debian.org
>
> Hi,
>
> On Sun, Dec 06, 2015 at 04:03:34PM +0000, Nicholas Bamber wrote:
>> Osamu,
>> 	I was just thinking about this because the internet is the modern day
>> equiavlent of the Wild West.
>
> i.e., never trust codes from the internet :-)
>
>>   It seems the bug report is fairly old and quite a lot of what is
>>   talked about has been implemented. However the essential issue is
>>   that some packages just do not fit into the normal mode.  "ksh" is an
>>   example. (The project is dead upstream so it deserves no
>>   consideration for that as well as being odd.) Such projects usually
>>   have a get-orig-source target in their rules file as specified in the
>>   policy:
>> http://www.debian.org/doc/debian-policy/ch-source.html.
>
> Script for uscan is sensitive issue.  Let's see the original bug:
>
>    https://bugs.debian.org/458789
>
> This is about running script while searching the new version string.
> That is handled with mangling rules under safe substitution method.
>
> Adding script running capability beats the whole purpose of
>    sub safe_replace ($$)
> to ensure safety of this part of action.  (uscan --report ...)
>
> Please read Jakub's message: https://bugs.debian.org/cgi-bin/458789#34
>
> I agree with him and I marked this #458789 as wontfix.
>
>>   So what we could do is build on that. The "custom" type watch file
>>   would run the "get-orig-source" target and treat a specified
>>   directory as the remote web page and parse that directory as if it
>>   were a web page.
>
> This is another issue.  repacking of tarball is done by mk-origtargz
> called from uscan.  See the bug report:
>    https://bugs.debian.org/cgi-bin/748474
>
> This talks about running script during repacking of tarball
> This part of code will not be run if --report is used.  All packaging
> crawling usages of uscan under the server environment do not come here.
>
> So I am not all that negative about adding some support for this
> feature of running script when repackaging.  (David!)
>
> I was initially thinking to add a watch line option pointing to a
> script... but as I read your message, your idea is better direction.
>
> As the policy indicates, the get-orig-source provide downloading feature
> too.  So there is an feature overlap with uscan.  We do not need
> "download" part.  If there is the "clean-orig-source" target exist,
> that is what mk-origtargz should run, I think.
>
> This "clean-orig-source" target maybe better interface than setting
> script name in watch file.  We can test script independently without
> reading manual :-) Just "./debian/rules clean-orig-source"
>
> Let's see what other people say.
>
> Osamu
>
>
>