Paul Wise <p...@debian.org> writes: > On Sat, Apr 7, 2018 at 4:40 PM, Ole Streicher wrote: > >> I have some packages where the version is not encoded in the file name, >> but must be extracted from the file content. Shall one keep >> get-orig-source here to be consistent, or what would be the right >> solution here? > > If uscan can find the right tarball, it will rename it correctly. > > If uscan cannot find a tarball, it will need assistance from a redirector. > > The fakeupstream CGI is a good place to add new redirectors. > > Please include some details and maybe we can add something.
I have a number of "uncommon" upstreams: * aladin, download http://aladin.unistra.fr/java/download/AladinSrc.jar look for the VERSION string in cds/aladin/Aladin.java and remove the leading "v" (and for Pre-releases, download AladinBetaSrc.jar, or a ad-hoc named jar, like AladinSrcV10Premiere.jar). * coyote, http://www.idlcoyote.com/programs/zip_files/coyoteprograms.zip look for the latest file date in the zip file (no upstream versioning) * idlastro, https://idlastro.gsfc.nasa.gov/ftp/astron.tar.gz similar (latest file date; no upstream versioning) * mpfit, https://cow.physics.wisc.edu/~craigm/idl/down/mpfit.tar.gz Take version number from "Revision" in mpfit.pro and add the latest file date * skyview, https://skyview.gsfc.nasa.gov/current/jar/skyview.jar look for "Version=" in skyview.settings * starjava-*, download via svn (subdir of https://github.com/Starlink/starjava) add the main LICENSE.txt file, get the version from build.xml property, and add latest file date (but download only tagged versions of starjava-topcat, starjava-ttools, and starjava-table). The rules may change over time (since I try to convince them to be more friendly here), so unless there is a flexible way for me to change them myself, I doubt it would be a good idea to put it there. But feel free to do so :-) Best Ole
