[MacPorts] #46575: submission of the Charm time tracker for Qt4 or Qt5

[MacPorts]

#46575: submission of the Charm time tracker for Qt4 or Qt5
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  Charm        |
--------------------------+--------------------------------

Comment (by ryandesign@…):

 Replying to [comment:4 rjvbertin@…]:
 > Replying to [comment:2 ryandesign@…]:
 >
 > >  * Why call `github.setup` with a commit hash? Why not use the 1.8.0
 tag?
 > I'm not really familiar with git tags, and I *guess* that using a commit
 tag gives a potentially new snapshot of a given version.

 Developers of most software projects commit changes to their software to
 their revision control system in logical chunks, called commits or
 revisions, and when they have finished a set of work they invent a new
 version number for the project, "tag" that version with a new version
 number, and release it to the world. Typically in MacPorts we want to
 follow a project's releases, not its commits, because commits typically
 represent an intermediate stage of development that may not be suitable
 for public consumption. On the other hand, sometimes the latest release
 has bugs that were fixed right after release, and in those cases we may
 use a newer commit, or add local patchfiles to deal with the issue.
 Sometimes developers release software very infrequently, and we may follow
 commits in that case, if we cannot convince the developers to adopt a more
 frequent release schedule.

 > >     Livecheck would work better and you wouldn't have to define
 `version` separately.
 >
 > Livecheck with git?

 Since we usually follow releases, not commits, usually we want livecheck
 to tell us about releases, not commits. That's what happens when you
 invoke `github.setup` with a tag (i.e. release) name. If, on the other
 hand, you invoke `github.setup` with a commit hash, then livecheck changes
 to tell you about newer commits.

 > >  * Why is `fetch.type git` necessary?
 >
 > I suppose it's redundant, then?

 Not at all. Perhaps you're confused about the difference between git and
 github. git is a client and server software program for managing a
 revision control system. github is a service that provides hosting for git
 repositories, issue trackers, wikis, web sites, code fragments, and so
 forth. In addition, github can generate tarballs for any revision or tag
 of any hosted git repository. The github portgroup sets up defaults
 appropriate for interacting with projects hosted at github, including
 using those tarballs. In MacPorts, we prefer ports to fetch their code
 from tarballs, zip files, or similar distfiles that are downloaded from a
 web or ftp server. This is preferred because the portfile lists checksums
 for each such file, so when the file arrives, you know it is identical to
 the one the port author used and tested. Furthermore, the MacPorts
 infrastructure automatically mirrors distfiles on a global network of
 servers, resulting in fault tolerance and faster downloads. Finally,
 distfiles are cached on the local system, so if you retry a build, you
 don't need to download the distfile each time. If you use `fetch.type
 git`, you indicate that you want to forgo all those advantages and
 communicate directly with the underlying git repository every time you
 build a port. There are some situations where that is needed, some
 examples of which are given in the comments in the github portgroup, but
 when it is not needed, it should be avoided.

 > >  * Remove the quotation marks around the value of the `conflicts`
 option; they're not needed.
 >
 > A bit confusing to know when they're needed or not!

 The most common reason to need quotes is if you are including whitespace
 in the variable's value, although even then it's only needed when dealing
 with pure variables (i.e. those you set with the Tcl command `set`), not
 MacPorts "options", which are a more advanced kind of variable.

-- 
Ticket URL: <https://trac.macports.org/ticket/46575#comment:19>
MacPorts <https://www.macports.org/>
Ports system for OS X