lldb ...

[Lawrence Velázquez]

> On Sep 9, 2016, at 7:38 AM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> I do a lot of development on projects for which I also maintain ports; in fact, development that's tightly coupled to the fact the code is available via a port. Doing all that work "as myself" only to transfer it to the port afterwards is a hassle and waste of time as far as I'm concerned. It's not so much that I want to avoid having to put sudo in front of each and every port command (I'd write a `sport` wrapper/alias). I don't want to grow the habit of putting sudo in front of everything I'm doing around those ports' build directories and that I'd also be doing in development that's got nothing to do with MacPorts. I also want to be able to open a port's source tree in an IDE, run incremental builds in subdirs for ${build.dir}, etc. So I've set my macportsuser to my own username, and most of the time I run everything up to and including `port destroot` as myself (and set up symlinks to `port work` for easy access). Typically, for -devel ports that use fetch.git I also replace ${worksrcdir} with a symlink to the working copy under my own home directory (that way I also won't lose local changes if I ever forget to use -o or -k).
> Many of the contributions I've made to KDE over the past few years were developed with this approach. I've used the standard approach (macportsuser = macports) on a VM Bradley gave me access to, and it's definitely a lot less productive.
> Evidently this is not the kind of advanced use we need to consider for regular users, but port developers/maintainers are users too, and I think we *could* consider their needs too.

Meh. There really aren't that many port developers, and I bet a lot fewer of them set macportsuser than you think.

We have no evidence either way, so appealing to an invisible mass of developers is not a convincing line of argument.

> As an aside, I'd be in favour of setting up MacPorts such that ${prefix} is owned by a ${macports_operator} who's got admin rights (= myself) and reserve use of actual root privilege to those few ports that require setting up SETUID/GETUID executables or that need to create users or groups. MacPorts installs into a parallel prefix, and there are only few ports that require access to system directories.

We consider the fact that we install as root to be a security feature. One can already install MacPorts as a non-root user if they want to.

>>>> Isn't that a bit of a special case, with you certainly having Apple's
>>>> benediction to work on that particular product?> > 
>>> XQuartz isn't any more blessed in that respect than MacPorts.
> 
> And the fact you're an Apple's payroll doesn't have anything to do with it either? Currently Apple doesn't have a say in the admission and upgrade of each and every port in MacPorts, do they? In a way I'd even hope they cannot force the exclusion of a port (other than ones clearly doing unlawful things); signing everything with an official key seems like a way to give them (more) leverage to control over the ports tree.

What? Apple provides developer certificates that can be used for signatures. Jeremy is suggesting we take advantage of this. Third-party developers do this all the time. Using a certificate doesn't give Apple review power over anybody (other than revocation in case of abuse).

vq
Sent from my iPhone