running macports along with homebrew

[db]

On 13 Feb 2018, at 19:52, Ken Cunningham <ken.cunningham.webuse at gmail.com> wrote:
> 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.