Opened 14 years ago

Closed 13 years ago

#26763 closed defect (fixed)

sane-frontends: fix livecheck

Reported by: aguynamedryan+macports@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: haspatch maintainer Cc:
Port: sane-frontends

Description

The attached patch fixes sane-frontends' livecheck. Before:

$ port livecheck
Error: cannot check if sane-frontends was updated (regex didn't match)

After:

$ port livecheck
sane-frontends seems to have been updated (port version:  45efdeabbf07f38ef0f8b3ca054b1cdc9fbb3f7, new version: 1928f945eefa3b97b5c76d586082435bb23c2969)

Please note I used an old SHA1 for ${git.branch} to get the "After" output. The most recent version is indeed 1928f9 and 'port livecheck' should really output nothing until the next time a commit is pushed to the master branch of the sane-frontends' git repo.

Attachments (1)

Portfile-sane-frontends.diff (445 bytes) - added by aguynamedryan+macports@… 14 years ago.
patch for livecheck

Download all attachments as: .zip

Change History (5)

Changed 14 years ago by aguynamedryan+macports@…

patch for livecheck

comment:1 Changed 14 years ago by jmroot (Joshua Root)

Keywords: haspatch maintainer added

comment:2 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)

Hashes like "45efdeabbf07f38ef0f8b3ca054b1cdc9fbb3f7" make for awful version numbers because hashes are not sequential; the epoch would have to be constantly incremented to accommodate this, and while that can be made to work, real dotted decimal version numbers, or if necessary just datestamps, tend to work better.

comment:3 Changed 14 years ago by aguynamedryan+macports@…

You are correct that a hash is a poor choice for a version number, as I learned in my port of pianobar.

However, the Portfile for sane-frontends currently lists the version as 1.0.15git which is the version output by scanadf --version There was much discussion about this in #25267 when I submitted the original Portfile.

It is my impression that until sane-frontends 1.0.15 is officially released, the SANE developers will continue to use 1.0.15git for all future updates to sane-frontends. It also appears that 1.0.15 might take a while to be released. 1.0.14 was released over 5 years ago. My plan was to track the master branch of the sane-frontends git repo and release a new revision to the sane-frontends port each time a new commit is made. New commits seem to be a rare event. In the last 4.5 years there have been 16 commits and only 1 commit in the last year.

Instead of resorting to an epoch, which I agree is heavy handed, couldn't we use a revision number in the Portfile to track updates I make to the port?

Hopefully that addresses the concerns about the sane-frontends version number. On to the reason for my patch: livecheck

While hashes aren't awesome for version numbers, they are good for tracking git commits. The patch I'm submitting deals with livecheck-ing the sane-frontends git repo. For the livecheck, I only want to know when the master branch has changed. I assume that a change to the master branch implies there is an update to sane-frontends that I need to investigate. The Portfile already has git.branch set for the fetch phase. It made sense to me to use that hash to compare against the sane-frontends git repo as opposed to storing the date of the last commit or something like that in the Portfile.

I've looked through most of the other ports that are using git.branch somewhere in their Portfile and my livecheck approach does seem unorthodox, but I didn't come across any solutions that fit my problem. Most other solutions relied on the upstream developers using tags or releasing new versions. I'm open to suggestions on better ways to do the livecheck in this situation where the SANE developers don't appear to be releasing or tagging new versions of sane-frontends.

comment:4 Changed 13 years ago by raimue (Rainer Müller)

Resolution: fixed
Status: newclosed

Committed in r90304.

Note: See TracTickets for help on using tickets.