On 05/05/2016 19:07, Christian Kastner wrote: > On 2016-05-05 17:16, Giulio Paci wrote: >>> One thing I'm not quite sure I follow yet is the change in the version >>> numbering scheme, both upstream and in the package. This is how it looks >>> to me: >>> >>> 1. Upstream re-used revision r1668 and added a -r3 suffix >>> -> "r1668" trades a bit of revision semantic for version semantic >>> >>> 2. Hence your switch to version semantic in d/changelog >>> >>> Is my interpretation correct? >> >> You are right. The change is due to the fact that they relied on svn revisions for releases in the past. Now they have switched to another repository (probably still svn), >> and I understand that they are around revision 70 on the new one. >> >> My understanding is that they have private versions of intermediate packages that they did not publish. >> >> I have not talked with upstream about this anyway. > > I'd do that when you get the chance, just to clarify what release plans > they have. Some upstreams may even benefit from a bit of guidance, eg: > > https://wiki.debian.org/UpstreamGuide#Releases_and_Versions Thank you for this pointer. I will probably do in future, if I will see further development happening. Unfortunately this software, as many other developed by students, is very important in its field, but lacks further development once the student is graduated. So I cannot foresee any future releases, unless I (or others) propose further changes and these are accepted. > In this particular case, I'd actually suggest that you stick to your > previous approach, and just modify it slightly: > > g2p-r1668.tar.gz => 0+r1668 > g2p-r1668-r3.tar.gz => 0+r1668.r3 (or even just keep -r3!) I decided to follow the suggestion from https://www.debian.org/doc/manuals/maint-guide/first.en.html#idp39551808 : "You should choose the upstream version to consist only of alphanumerics (0-9A-Za-z), plus (+), tildes (~), and periods (.). It must start with a digit (0-9)." > The solution above retains the largest flexibility in the face of > the current ambiguity. For example, if upstream were to release a version > '0.0.1', your new solution would no longer work: > > $ dpkg --compare-versions '0.0.r1668.3-1' lt '0.0.1-1' || echo "oops!" > oops! You are right. I am still wondering how it happened that I changed the version scheme... Probably the error came from the watch file... Anyway it should be fixed now. > You can achieve the aforementioned modification by chaining patterns in > uversionmangle using a semicolon. Based on your previous version: > > -opts="uversionmangle=s/^(.*)$/0+$1/" > +opts="uversionmangle=s/^(.*)$/0+$1/; s/-r(\d+)/.r$1/" > > $ uscan --report-status | grep -A4 'newest first' > uscan info: Found the following matching hrefs on the web page (newest first): > g2p-r1668-r3.tar.gz (0+r1668.r3) index=0+r1668.r3-1 > g2p-r1668.tar.gz (0+r1668) index=0+r1668-1 > g2p-r103.tar.gz (0+r103) index=0+r103-1 > g2p-r96.tar.gz (0+r96) index=0+r96-1 > > On a side note: I believe you can simplify the version matching pattern > in your watch file. You currently match for many possible suffixes, but > upstream apparently only uses .tar.gz. I simplified suffix matches. Bests, Giulio
Attachment:
signature.asc
Description: OpenPGP digital signature