Re: Debian Policy 4.1.4.0 released
Paul Wise <pabs@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
Reply to: