Re: running macports along with homebrew

[Julien Salort]

Le 15/02/2018 à 00:42, Michael a écrit :


I think we should look at ways in which MacPorts is harder to use and see if we 
can address those.

I'd say that being able to install software without having to use sudo would be 
my number one.

So, maybe a --user switch, similar to Python pip's ?
Or, possibly environments like Python venv or conda's ?

Julien

Re: running macports along with homebrew

[Chris Jones]

Hi

On 14/02/18 23:42, Michael wrote:

I think we should look at ways in which MacPorts is harder to use and see if we 
can address those.


I'd say that being able to install software without having to use sudo would be 
my number one.



Personally, one of the reasons I choose MacPorts over the alternatives 
many years back when I was new to OSX was precisely *because* MacPorts 
uses sudo to install, and not my regular user account. I want the 
software installation prefix controlled by an account I do not have 
write access to by default...


What exactly are your problems with using sudo ? If its just the fact 
you have to enter a password, then that is easily solvable by you just 
editing your sudoers file, to give your user account access to run the 
port command via sudo without needing to give it. I always do this on 
the systems I work on, as it allows me to run port without the 
inconvenience of entering the password all the time, but with all the 
benefits of having the installation read only other wise.


Just my thoughts, but MacPorts should not be looking to change its way 
of working to match what the likes of homebrew does. We should embrace 
what makes it different (better) and instead put more emphasis to 
explain that.


One thing perhaps we could do is look more at the web site. No offense 
to the maintainers, but I think if average user looking into package 
managers looks at our respective web sites, its not perhaps that 
surprising why at that first point of contact with them they drift more 
to homebrew. If we want get more of those users, that is IMHO where we 
should first make the effort...


cheers Chris

Re: running macports along with homebrew

[Craig Treleaven]

> On Feb 14, 2018, at 2:46 PM, Ken Cunningham  
> wrote:
> 
> 1. a one-line copy-paste install script that can be embedded into any webpage.

I could never understand that this is considered an advantage of Homebrew.  The 
idea of running a random script directly from a web page that purports to 
install useful software.  

Craig

Re: gdb fails to compile on Leopard - C++11 compiler

[Riccardo Mottola via macports-users]

Hi,

I forgot to reply this!

Chris Jones wrote:


It appears the port already has support for building against MPs 
python versions, it just is not enabled by default.


Titan ~/Projects/MacPorts/ports > port variants gdb
gdb has the variants:
   multiarch: Support all target architectures
   python27: Build GDB with Python 2.7 Scripting
 * conflicts with python35 python36
   python35: Build GDB with Python 3.5 Scripting
 * conflicts with python27 python36
   python36: Build GDB with Python 3.6 Scripting
 * conflicts with python27 python35
   universal: Build for multiple architectures

so try enabling one of the above variants.



enabling even just python27 worked.. so the only issue is taht there is 
no "default" working variand.


I used the gdb a bit and it appears to work for what I needed, much 
better than the obsolete system one.


the "PortGroup cxx11 1.1" fix is needed, would you make it ?


Riccardo

Re: running macports along with homebrew

[Dr M J Carter]

On Thu, Feb 15, 2018 at 08:39:23AM -0600, Ryan Schmidt wrote:
> On Feb 14, 2018, at 17:16, db wrote:
> 
> > I couldn't find elasticsearch in macports.
> 
> $ port info elasticsearch
> elasticsearch @6.1.2 (databases, java)
[snip]

Not there on my desksystem, but there on one of our test builders;
Portfile dated Jan 23rd.  HTH.

-- 
Dr Martin J Carter
Computer System Administrator
Astrophysics, University of Oxford

Re: running macports along with homebrew

[Ryan Schmidt]

On Feb 14, 2018, at 13:46, Ken Cunningham wrote:

> On 2018-02-14, at 5:56 AM, Ryan Schmidt wrote:
> 
> 
>> We will definitely never offer a user-facing feature for building the HEAD 
>> version of a port's code. 
> 
> 
> I completely recognize why you stick with this, I totally get it, but this 
> caution is costing MacPorts both users and mindshare to do so... some people 
> want this, and so will go elsewhere to get it.

If you refer specifically to the fact that we don't support building a port 
from HEAD, I've literally never heard anyone ask for that feature on the 
MacPorts lists, until this thread.


> In a recent poll 
> , homebrew was 
> recommended 375 to 25 over MacPorts.
> 
> Most developers who offer their software for download and building manually 
> recommend homebrew for supporting software. Almost nobody recommends MacPorts.

I'm sorry to hear that.


> Reasons for this are likely to be:
> 
> 1. a one-line copy-paste install script that can be embedded into any webpage.
> 
> 2. symlinks into /usr/local therefore:
>a) no adjustments needed to path

The MacPorts installer adds /opt/local to the PATH. So MacPorts requires no 
manual adjustments of the PATH either.

>b) no need for sudo

That does not follow. We use sudo because it increases security to do so.

>c) third-party apps, libraries, and xcode projects can be downloaded and 
> built or run, and the system looks there by default, so need no modification 
> to build or run. 

Nothing prevents portfiles from being written that install things people want 
installed. We certainly have ports that install apps and libraries. I don't 
understand why anyone would want a port that installs an Xcode project. I don't 
know what you mean by "system looks there by default".

> 3. you can easily build the +HEAD version of a git project to try out newest 
> changes as a beta tester
> 
> 
> IMHO, the two biggest reasons homebrew is heavily recommended are #1 and #2c. 
> I think it's just good that we all know this.

I have heard some complaints about our installation process before. Running a 
single installer package should not be too onerous; lots of software is 
successfully distributed in that way. It is perhaps inconvenient that we 
require the user to install Xcode and the command line tools first. Some work 
has been done to streamline that to the point that only Xcode and not the 
command line tools will be required for MacPorts 2.5 and up. I'm not certain if 
we could streamline it further. Perhaps the installer could contain more 
prominent links to download Xcode from the App Store or something.


> Question:
> 
> Is there anything that would stop someone from installing macports into 
> /usr/local , should they desire to do so? That would fix up all the issues 
> with sudo, path, and 2c.

Yes, the MacPorts configure script deliberately prevents users from selecting 
/usr/local as their prefix, because doing so would cause problems and we do not 
want to experience the support burden of users doing so.

https://trac.macports.org/wiki/FAQ#defaultprefix

Re: running macports along with homebrew

[Ryan Schmidt]

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.

Re: running macports along with homebrew

[Ryan Schmidt]

On Feb 14, 2018, at 17:42, Michael wrote:

>> I think we should look at ways in which MacPorts is harder to use and see if 
>> we can address those.
> 
> I'd say that being able to install software without having to use sudo would 
> be my number one.

Step 1: edit the sudoers file so that you are allowed to run "sudo port" 
without typing a password.
Step 2: add a shell alias so that running "port" is the same as running "sudo 
port".