Web lists-archives.com

Re: Debian Policy 4.1.4.0 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
> 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