Re: uscan for a single text file
Sergio Durigan Junior <sergiodj@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
Reply to: