On 13 Feb 2018, at 19:52, Ken Cunningham <ken.cunningham.web...@gmail.com>
> 1. cask:
> I think nobody finds this in general to be all that magical or useful though,
> and so nobody bothers to spend any time on building these sorts of Portfiles.
> You want Adobe Air? Just go to the website and install it.
It's going to every site n times vs. one command to install n applications plus
another to uninstall them and their related files (plists, caches).
> 2. HEAD variants.
> This is a specific MacPorts decision, based on the "reproducible builds"
> philosophy. It's open for debate at times, I would think. It's easy to do
> it, but we just don't do it on purpose.
> I have overridden this and allowed a +HEAD variant on one occasion at the
> request of a heavy user of the software (see the widelands Portfile).
> Anyone with a passing level of MacPorts knowledge can bump a Portfile to the
> latest commit on their own in a few seconds, esp if it uses the github
> Portgroup. I do this all the time.
> This could be added quite easily if MacPorts wanted to do it -- a small
> change in the github portgroup would likely suffice to add a +HEAD variant to
> all github ports.
I have some devel ports locally, that I have to manually update for the latest
commit, instead of automatically updating for the current master. I have to
check that wielands port.
> 3. LinuxPorts
> I think Rene has this working (@RJVB). Haven't tried it, though. I bought a
> couple of linux machines for this reason, but just ran out of time to play
> with them.
Do you mean this repo  or am I missing something?
> 4. Vagrant and ELK
> I can take a look at these.
There's a ticket for vagrant. I used it as a starting point, but eventually
gave up. And, if you have a chance and could review the portfiles I submitted
for ipfs and stem, a while ago.