On Feb 14, 2018, at 17:16, db wrote: > On 14 Feb 2018, at 14:56, Ryan Schmidt wrote: >> I'm aware of "cask" being a feature of Homebrew. If that's what you're >> referring to, what does the feature do / what do you want MacPorts to do in >> regard to this? > > Manage (and here the terminology gets trickier) more generally available > application bundles, from DEVONthink to ungoogled chromium.
I assume the implication is that these are application bundles that have been compiled and distributed by developers, as opposed to building from source like we usually do. We could certainly begin offering ports that repackage existing developer-provided binaries, though I'm not convinced of the value of doing so. Generally available application bundles usually include their own autoupdate mechanism. If we were to include them in MacPorts, we would need to disable such autoupdate mechanisms, but it isn't always clear how to do so. For programs using Sparkle, for example, is it sufficient to delete the Sparkle framework from the application bundle, or will that cause the application to crash? Will it have any adverse effect on the application signature, if there is one? These might be answerable questions but I don't know if anyone has attempted to answer them yet. >> We will definitely never offer a user-facing feature for building the HEAD >> version of a port's code. > > I still think the feature should be added, specially for devel ports, even if > it's not supported when problems arise. Offering such a feature will give users a new way of shooting themselves in the foot. Even if we say we don't support it when problems arise, users will report problems, and it will take our time and effort to determine that the problems they're encountering are because of this. I prefer to use my time for other things. >>> LinuxPorts (analog to Linuxbrew), >> What does this do / what do you want this to do? > > I haven't tried it yet, but I guess I could install the same or similar set > of tools using the same package manager interface. If you mean *on Linux*, then MacPorts base does run on Linux, but there's probably less than two people who actually try to install ports on Linux, so you'll find a lot of ports that won't install correctly on Linux. We don't have the manpower to deal with all the issues filed by Mac users, so it seems unlikely we would have the manpower to deal with issues on less-well-supported platforms. If it's important to you, you can try it and help fix the issues you find. But there's probably not a great deal of interest because there are other package managers for Linux already. >> I see a submission for rb-vagrant; is that the same thing? >> https://trac.macports.org/ticket/43225 > >> elasticsearch is in MacPorts. >> The submissions of logstash and kibana are here: >> https://trac.macports.org/ticket/44824 >> https://trac.macports.org/ticket/44822 > > I couldn't find elasticsearch in macports. $ port info elasticsearch elasticsearch @6.1.2 (databases, java) Description: Elasticsearch is a highly scalable open-source full-text search and analytics engine. It allows you to store search, and analyze big volumes of data quickly and in near real time. It is generally used as the underlying engine/technology that powers applications that have complex search features and requirements. Elasticsearch requires Java, Java version can be up to Java 8. Java 9 is not supported and Elasticsearch won't work. Homepage: https://www.elastic.co/ Extract Dependencies: unzip Platforms: darwin License: Apache-2 Maintainers: GitHub: gerardsoleca Policy: openmaintainer > The submissions for vagrant, logstash and kibana are abandoned or work in > progress since more that 3 years. That can happen. If you or anyone is interested in finishing these up so that they can be included, please do.
