Paul Wise <p...@debian.org> writes: > On Sat, Apr 7, 2018 at 8:49 PM, Ole Streicher wrote: > >> I have a number of "uncommon" upstreams: > > It would be really nice if these folks could switch to something more > standard. Have they considered using a version control system for a > start?
I asked, but this did not result in a change. >> * 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). > > The version number can be obtained here: > > http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=downloading > > With a pagemangle, uscan could detect the version and associated > tarball. Only when the version number on the web page does match to the version number in the file. Which is often enough not the case. >> * coyote, http://www.idlcoyote.com/programs/zip_files/coyoteprograms.zip >> look for the latest file date in the zip file (no upstream versioning) > > There is apparently a github org for this: > > https://github.com/idl-coyote > > With a pagemangle, you can get the latest date from that: > > https://sources.debian.org/src/purple-discord/latest/debian/watch But it is a difference between a github commit and a released zip file. Even if it does not contain a version number, it is usually somehow better curated. >> * idlastro, https://idlastro.gsfc.nasa.gov/ftp/astron.tar.gz >> similar (latest file date; no upstream versioning) > > There is apparently a github repo for this, use pagemangle: > > https://github.com/wlandsman/IDLAstro Dito. >> * 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 > > This contains the mpfit.pro Revision and all dates, use pagemangle: > > https://cow.physics.wisc.edu/~craigm/idl/down/cmtotal.txt This file is three times of the size of than mpfit.tar.gz, containing a lot more (versionized) files. > PS: the $Id things are from CVS, could you ask upstream to publicly > expose their CVS repository? In that specific case, I didn't. However, also here I would resist in using the plain RCS version, but rely on upstreams version curation. >> * skyview, https://skyview.gsfc.nasa.gov/current/jar/skyview.jar >> look for "Version=" in skyview.settings > > The version number is listed on two pages, use pagemangle: > > https://skyview.gsfc.nasa.gov/current/cgi/titlepage.pl > https://skyview.gsfc.nasa.gov/blog/ > > Unfortunately both are outdated compared to the jar... That is the problem here. When the version number is unreliable, it cannot be used. >> * 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). > > uscan can deal with git repos just fine. Also with subtrees? >> 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. > > We could add you to the salsa qa group so you can commit them, but > given the above I think most are best dealt with by uscan. I would think that I am just a random example, and you probably wouldn't want to give write access to all that are affected. But could you point me to the documentation how to write a redirector? I could also do a Merge Request. Best regards Ole