> On Sep 9, 2016, at 7:38 AM, René J.V. Bertin <[email protected]> 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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
