On Wed, 31 Oct 2018 at 18:25, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
Looking at this further, this URL scheme is just terrible and will be
"fun" to make use of.
Basically you have to keep in mind that a tool like spectool can't trust
the filename that is sent by the remote web server and will instead use
only the filename extracted from the URL.
That means if you use something like this:
Source0:
https://cran.r-project.org/package=%{packname}&version=%{version}
you'll get a filename like
package=webp&version=0.4
(for a random package, R-webp, that I grabbed).
Correct.
And that's not a useful filename; rpm won't unpack it.
But that URL, for instance:
https://cran.r-project.org/package=simmer&version=3.0.0
returns a redirection (303) to the complete URL, with file extension.
What you have to do is the somewhat painful:
Source0:
https://cran.r-project.org/package=%{packname}&version=%{version}#/%{...
Now, since we're going to hide this behind a macro, it's not the worst
thing in the world. But it leaves questions:
* Is this guaranteed to continue to work in future? I don't think that
the remote host gets the URL fragment identifier at all so I think it
should be OK, but I haven't really tested that.
CRAN maintainers are pretty strict with this kind of stuff: if it
works now, it's guaranteed to continue to work.
* Since we need to know the extension, can we expect tar.gz or are
there
packages with other archive formats?
There are no other formats: every package is tar.gz. But, as I pointed
out above, the immutable URL is a redirection to the complete URL, so
you can still extract the extension.
So, I think we can deal but I don't think CRAN considered this point at
all and that's unfortunate.
- J<
--
Iñaki Ucar