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