On Sunday, July 17 2016, Ole Streicher wrote: > Sergio Durigan Junior <sergi...@sergiodj.net> writes: >> On Saturday, July 16 2016, Ole Streicher wrote: >> >>> Sergio Durigan Junior <sergi...@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.
It makes sure that there is a tarball compressed using the supported compression mechanisms, even when it is not interested in unpacking the tarball. This is a design decision, and I don't know why it was made this way. I obviously agree with you that it could be improved. I agree with Paul Wise when he says that mk-origtargz should create a tarball if the file provided by the user is not one. I guess I'll give this idea a try later (when I have time). >> 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. uupdate not only creates the symlink, but also does some "house-keeping" (it makes sure debian/rules is executable, for example). It will perform different tasks depending on the version you specify in your watch file. > 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. Actually, I think it makes more sense to extend mk-origtargz and make it honour its name: create an .orig.tar.gz tarball *even* when upstream does not provide a tarball. > 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? Hm, I couldn't find any casacore-data package. But I found the casacore package, which points me to <https://github.com/casacore/casacore> as its upstream. There, I could find the .tar.gz file provided by git tags, so I'm not sure if I understood your question, sorry. Could you expand it to me, please? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/
signature.asc
Description: PGP signature
