On 13 Feb 2018, at 19:52, Ken Cunningham <ken.cunningham.web...@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.
