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 [1] or am I missing something?

[1] https://github.com/RJVB/lnxports

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

Reply via email to