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 748...@bugs.debian.org
Please drop 458...@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
