Re: Debian Policy 22.214.171.124 released
- Date: Sun, 08 Apr 2018 10:54:24 +0200
- From: Ole Streicher <olebole@xxxxxxxxxx>
- Subject: Re: Debian Policy 126.96.36.199 released
Paul Wise <pabs@xxxxxxxxxx> 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
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:
> With a pagemangle, uscan could detect the version and associated
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:
> With a pagemangle, you can get the latest date from that:
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:
>> * 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:
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:
> 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
>> 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