Sergio Durigan Junior <sergi...@sergiodj.net> writes: > On Sunday, July 17 2016, Ole Streicher wrote: >> 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.
it is done at the wrong place, since mk-origtargz is called before uupdate, and uupdate is still able to change the tarball (this is even recommended by some tutorials). > 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). IMO there should be an option that the user can decide how the tarball is created from the downloaded file(s). >> 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). that sounds a bit arbitrary: uscan is made for the preparation of the original tarball. Why should it touch d/rules? Especially, since usually uscan is called for a package that has already an older version (and therefore also a working d/rules). If there is really a problem with wrong permissions on d/rules, it would (IMO) be better to let lintian complain here. > It will perform different tasks depending on the version you specify > in your watch file. I mean 3/4 only (everything else was before my time). uscan downloads the file mk-origtargz repacks it (if needed) or created the symlink what other housekeeping is needed to reach its goal? The manpages states: | uscan invokes uupdate to create the Debianized source tree: but isn't this a step that is highly dependent on the used workflow? If I use git-buildpackage (or any other bit-based workflow); why whould I need to create a debianized source tree? >> 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. I mean: it should be done at the place of uupdate, and easily replaceable by another script if needed. The name does not matter here. >> 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? Sure: casacore is the "base" package, which is now in Debian. For a proper work, it needs some data files, which are currently "somehow" created upstream and put together into a single tarball. Just using this tarball is IMO not acceptable by the Debian policy, since we insist in having sources. So, I pushed the casacore maintainers to make the tarball creation transparent and to do it when creating the casacore-data package. It appears that the tarball is created by downloading several ASCII data files from different location (f.e. about the earth magnetic field), and then processed by a program distributed with casacore. Therefore my proposed way is: * create one source package for each topic/download location * do the processing when creating the binary packages. The simplest case here is the one which was used to start this discussion: the source is just one data file for the earth magnetic field. The other source packages will be more difficult, since they download several (up to 100) files; probably the uscan mechanism will fail here (also because the file names do not contain a version or so). We discussed that a while ago in the debian-astro mailing list. Best regards Ole
