[MacPorts] #31389: hexfiend change from svn to tarball

MacPorts noreply at macports.org
Sat Oct 22 01:33:45 PDT 2011


#31389: hexfiend change from svn to tarball
--------------------------------------+-------------------------------------
  Reporter:  and.damore@…             |       Owner:  dweber@…           
      Type:  update                   |      Status:  closed             
  Priority:  Normal                   |   Milestone:                     
 Component:  ports                    |     Version:  2.0.3              
Resolution:  fixed                    |    Keywords:  haspatch           
      Port:  hexfiend                 |  
--------------------------------------+-------------------------------------
Changes (by ryandesign@…):

 * cc: ryandesign@… (added)
  * status:  new => closed
  * resolution:  => fixed


Comment:

 Replying to [ticket:31389 and.damore@…]:
 > I'm attaching a diff that switches portfile from svn rev 17 (current is
 273) to 2.0.0 tarball.

 Thanks. Committed in r86223 with these changes:

  * when the version goes "backward" (e.g. from "17" to "2.0") the epoch
 must be increased
  * removed comment about svn fetching which is no longer applicable
  * indicated license
  * installed license file
  * rewrote master_sites and homepage
  * simplified distfiles and worksrcdir down to just distname
  * added dist_subdir; see wiki:PortfileRecipes#unversioned-distfiles
  * removed unnecessary quoting in destroot

 > I'd capitalize the name of the port too, both 'h' and 'f', like many
 ports in aqua category do.

 I did not change the name of the port because I do not know how MacPorts
 would handle a change in case during an upgrade. MacPorts was never
 designed to handle that, so it might not do it correctly, and it might
 vary based on whether the filesystem is case-sensitive or not.

 Lowercase port names used to be preferred because of a bug in MacPorts
 base. That was fixed years ago so for new ports uppercase characters can
 be used where needed. But case-only renames of existing ports are probably
 best avoided (unless someone wants to do some detailed testing on various
 systems and prove that it works, ideally writing some tests we can add to
 MacPorts base). If this is something you're interested in, feel free to
 bring it up on macports-dev and I'll explain some of the concerns I have.

-- 
Ticket URL: <https://trac.macports.org/ticket/31389#comment:1>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list