Opened 13 years ago

Closed 12 years ago

#31389 closed update (fixed)

hexfiend change from svn to tarball

Reported by: anddam (Andrea D'Amore) Owned by: dweber@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: haspatch Cc: ryandesign (Ryan Carsten Schmidt)
Port: hexfiend

Description

I'm attaching a diff that switches portfile from svn rev 17 (current is 273) to 2.0.0 tarball.

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

Attachments (1)

port-hexfiend.diff (1.8 KB) - added by anddam (Andrea D'Amore) 13 years ago.

Download all attachments as: .zip

Change History (2)

Changed 13 years ago by anddam (Andrea D'Amore)

Attachment: port-hexfiend.diff added

comment:1 in reply to:  description Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added
Resolution: fixed
Status: newclosed

Replying to 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.

Note: See TracTickets for help on using tickets.