Re: uscan for a single text file
Sergio Durigan Junior <sergiodj@sergiodj.net> writes:
> On Saturday, July 16 2016, Ole Streicher wrote:
>
>> Sergio Durigan Junior <sergiodj@sergiodj.net> writes:
>>>> What is wrong here? I thought that mk-orig.tar.gz should be called only
>>>> when it is a tar archive?
>>>
>>> Yeah, uscan is the responsible for invoking mk-origtargz. That can be a
>>> problem indeed for cases like yours.
>>
>> Hmm, the manpage of uscan says:
>>
>> | Please note the repacking of the upstream tarballs by mk-origtargz
>> | happens only if one of the following conditions is satisfied:
>> | · USCAN_REPACK is set in the devscript configuration.
>> | · --repack is set on the commandline.
>> | · repack is set in the watch line as opts="repack,...".
>> | · The upstream archive is of zip type including jar, xpi, ...
>> | · Files-Excluded or Files-Excluded-component stanzas are set in
>> | debian/copyright to make mk-origtargz invoked from uscan remove
>> | files from the upstream tarball and repack it.
>>
>> Non of these is true in my case. So, isn't this a bug in uscan?
>
> This snippet refers to the repacking of the upstream tarball. Even when
> no repacking is needed/requested, mk-origtargz is still invoked (it is
> resposible for creating the symlink to the .orig.tar.gz file, for
> example).
If mk-origtargz doesn't repack it, why does it look into it? The symlink
could be created without as well.
> yeah, as I mentioned to Gianfranco I also think it is worth adding an
> option to disable the execution of mk-origtargz. I went ahead and
> submitted the following:
>
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831521>
Great. Thanks.
> Yeah, it is curious that mk-origtargz and uupdate both create the same
> symlink from the original tarball to the .orig tarball.
What is the use of uupdate in current workflows (f.e. git-buildpackage)
at all? In my opinion, it is bound to one very specific workflow, which
at least I personally never used. And the rest of the watch/uscan
procedure is workflow-agnostic; it is just the canonical way to get a
new upstream tarball.
So wouldn'it it be better to just replace uupdate by an adjusted
mk-origtargz script? Then, one could replace it by an specific script if needed.
BTW, in the queue of casacore-data packages we would also need a watch
file + script for packages which download ~100 individual files and put
them into a tarball (Upstream doesn't offer a tar download option). Any
good ideas here?
Best regards
Ole
Reply to: