It seems that selfupdate got broken: prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/wd/macosx/dports" It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here: file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports But I use this for port installation only. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On May 10, 2007, at 09:44, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/ wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
According to the change notes, sync was intentionally changed to also update sources which are Subversion working copies. It's supposed to be a new feature, not a bug. Not sure why you need three ports trees... I get by just fine with just one.
On May 10, 2007, at 7:44 AM, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/ wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
As Ryan points out, this was a change in 1.4.40. Clearly whoever made the change did not anticipate the problem you're having with it. We'd love to hear your suggestions for what the proper behavior should be in this case. What if the behavior was: - Update the first sources.conf directory found that either (1) is an rsync url, or (2) is a valid svn repository. Would that rule fix things for you? James
-- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/ blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS- Lyon) _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Ryan Schmidt wrote:
On May 10, 2007, at 09:44, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
According to the change notes, sync was intentionally changed to also update sources which are Subversion working copies. It's supposed to be a new feature, not a bug.
I don't think it should do update the working copy. I have a working copy checked out with my non-root account and I do work in there as non-root. I don't want a root owned svn to go in their making new files owned by root, so that I do have to sudo to do any svn operations. Also, I have other processes that update that and do diffs and other things on the MacPorts checkout, so I'd rather not have port selfupdate do it. Can we make it configurable and make the default false? Regards, Blair
On 2007-05-10 15:55:53 -0700, James Berry wrote:
On May 10, 2007, at 7:44 AM, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
As Ryan points out, this was a change in 1.4.40. Clearly whoever made the change did not anticipate the problem you're having with it. We'd love to hear your suggestions for what the proper behavior should be in this case. What if the behavior was:
- Update the first sources.conf directory found that either (1) is an rsync url, or (2) is a valid svn repository.
I suppose you meant "is a valid working copy".
Would that rule fix things for you?
No, because the working copy is valid (the repository is also valid, but root cannot connect to it). First, the source.conf format should probably be changed so that one can tell which sources need to be updated by selfupdate and taken into account to upgrade MacPorts (the user may want to use some sources for the ports, and some other source for MacPorts itself). Second, if the directory doesn't belong to the user running the "port" command, then it should not be updated. Otherwise this is a real mess (in particular if one uses sudo). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On 2007-05-10 17:41:57 -0500, Ryan Schmidt wrote:
On May 10, 2007, at 09:44, Vincent Lefevre wrote: [...]
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
According to the change notes, sync was intentionally changed to also update sources which are Subversion working copies. It's supposed to be a new feature, not a bug.
Not sure why you need three ports trees... I get by just fine with just one.
file:///Users/vinc17/wd/macosx/dports is my private tree. Of course, it must not be updated by selfupdate. and historically (AFAIK): file:///Users/vinc17/software/dports was the trunk. rsync://rsync.macports.org/dpupdate/dports was stable. In fact, I want the development tree for the ports, and something stable for MacPorts itself. But I don't know if the above is still valid. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
James Berry wrote:
On May 10, 2007, at 7:44 AM, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only.
As Ryan points out, this was a change in 1.4.40. Clearly whoever made the change did not anticipate the problem you're having with it. We'd love to hear your suggestions for what the proper behavior should be in this case. What if the behavior was:
- Update the first sources.conf directory found that either (1) is an rsync url, or (2) is a valid svn repository.
Would that rule fix things for you?
James
And it also doesn't work if you have a MacPorts install with everything deactivated, which I do so I can commit the binary build into a Subversion repository (for checking out on many Mac's). $ port -d -v selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///net/homedirs/blair/Code/MacPorts/dports-spi Synchronizing from file:///net/homedirs/blair/Code/MacPorts/dports-macports.org DEBUG: Couldn't sync dports tree: svn command not found while executing "darwinports::selfupdate [array get global_options]" Error: /opt/local/bin/port: selfupdate failed: Couldn't sync dports tree: svn command not found Even trying to hack it by doing this fails: $ /usr/bin/true /tmp/svn $ PATH=/tmp:$PATH port -d -v selfupdate Who made these changes? I don't see anybody working on this. Can we back out those commits that did this until it's working fine and reach a consensus on what its supposed to do, or even if we want it. Thanks, Blair
Hi Blair, Kevin Ballard (Eridius) made this change. I know he's been thinking about it and trying to make it work better, but I'd suggest you enter a dialogue with him, which could end in the "feature" being pulled or in being made to work to your (and others) satisfaction. James. On May 15, 2007, at 10:30 AM, Blair Zajac wrote:
James Berry wrote:
On May 10, 2007, at 7:44 AM, Vincent Lefevre wrote:
It seems that selfupdate got broken:
prunille:~> sudo port -d selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///Users/vinc17/wd/macosx/dports DEBUG: /opt/local/bin/svn update --non-interactive "/Users/vinc17/ wd/macosx/dports"
It shouldn't update *my* SVN working copy. It was previously updating the standard path (?) with rsync. I suppose that it takes the paths from /opt/local/etc/ports/sources.conf, which contains here:
file:///Users/vinc17/wd/macosx/dports file:///Users/vinc17/software/dports rsync://rsync.macports.org/dpupdate/dports
But I use this for port installation only. As Ryan points out, this was a change in 1.4.40. Clearly whoever made the change did not anticipate the problem you're having with it. We'd love to hear your suggestions for what the proper behavior should be in this case. What if the behavior was: - Update the first sources.conf directory found that either (1) is an rsync url, or (2) is a valid svn repository. Would that rule fix things for you? James
And it also doesn't work if you have a MacPorts install with everything deactivated, which I do so I can commit the binary build into a Subversion repository (for checking out on many Mac's).
$ port -d -v selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///net/homedirs/blair/Code/MacPorts/dports-spi Synchronizing from file:///net/homedirs/blair/Code/MacPorts/dports- macports.org DEBUG: Couldn't sync dports tree: svn command not found while executing "darwinports::selfupdate [array get global_options]" Error: /opt/local/bin/port: selfupdate failed: Couldn't sync dports tree: svn command not found
Even trying to hack it by doing this fails:
$ /usr/bin/true /tmp/svn $ PATH=/tmp:$PATH port -d -v selfupdate
Who made these changes?
I don't see anybody working on this. Can we back out those commits that did this until it's working fine and reach a consensus on what its supposed to do, or even if we want it.
Thanks, Blair
Blair, when I made the change it searched PATH for svn and ran that. I think it was jberry who added a ./configure directive to hardcode the path at configuration time, however if it can't find that path I believe it still falls back on searching PATH for it. The only reason it should fail to find svn for you is if you do not, in fact, have an svn binary in your path. I'm not sure what your `/usr/bin/true /tmp/svn` line was supposed to do. /usr/bin/true simply returns 0 and ignores arguments. Here's a possible solution - in $prefix/etc/ports/sources.conf, we could have a [nosync] directive after a source to tell dportsync not to sync it. Would that work for you? On May 15, 2007, at 1:36 PM, James Berry wrote:
Kevin Ballard (Eridius) made this change. I know he's been thinking about it and trying to make it work better, but I'd suggest you enter a dialogue with him, which could end in the "feature" being pulled or in being made to work to your (and others) satisfaction.
James.
On May 15, 2007, at 10:30 AM, Blair Zajac wrote:
And it also doesn't work if you have a MacPorts install with everything deactivated, which I do so I can commit the binary build into a Subversion repository (for checking out on many Mac's).
$ port -d -v selfupdate DEBUG: Rebuilding the MacPorts base system if needed. Synchronizing from file:///net/homedirs/blair/Code/MacPorts/dports-spi Synchronizing from file:///net/homedirs/blair/Code/MacPorts/dports- macports.org DEBUG: Couldn't sync dports tree: svn command not found while executing "darwinports::selfupdate [array get global_options]" Error: /opt/local/bin/port: selfupdate failed: Couldn't sync dports tree: svn command not found
Even trying to hack it by doing this fails:
$ /usr/bin/true /tmp/svn $ PATH=/tmp:$PATH port -d -v selfupdate
Who made these changes?
I don't see anybody working on this. Can we back out those commits that did this until it's working fine and reach a consensus on what its supposed to do, or even if we want it.
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
BTW, I've already fixed this particular issue in trunk. Port will now run svn as the user who owns the WC. On May 10, 2007, at 7:01 PM, Blair Zajac wrote:
I don't think it should do update the working copy. I have a working copy checked out with my non-root account and I do work in there as non-root. I don't want a root owned svn to go in their making new files owned by root, so that I do have to sudo to do any svn operations.
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On 2007-05-15 15:20:59 -0400, Kevin Ballard wrote:
Here's a possible solution - in $prefix/etc/ports/sources.conf, we could have a [nosync] directive after a source to tell dportsync not to sync it. Would that work for you?
It would be a good idea (in addition to the permission test). -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On May 15, 2007, at 3:20 PM, Kevin Ballard wrote:
Blair, when I made the change it searched PATH for svn and ran that. I think it was jberry who added a ./configure directive to hardcode the path at configuration time, however if it can't find that path I believe it still falls back on searching PATH for it.
This is essentially what the findBinary proc I wrote for (darwin|mac) ports1.0 in my dp2mp-move branch does: it searches an autoconf module for the path to a binary and falls back on the PATH if it doesn't find it there. That functionality is not yet in trunk, however, the whole branch is still in testing (though approaching rc status as of the last days). My approach will not correct Blair's situation either, though, since the svn program is neither in the autoconfiscated location nor anywhere in the path (the port is deactivated). In that case, a nosync flag is the only viable solution I can see, other than removing the syncing file sources feature entirely (or commenting out the source while the sync takes place... or.. any other way of manually avoiding to sync the source in question). -jmpp
Ok, r25236 adds support for the [nosync] directive. What do you mean by a permission test? dportsync already runs svn update as the owner of the working copy (in trunk). On May 15, 2007, at 6:25 PM, Vincent Lefevre wrote:
On 2007-05-15 15:20:59 -0400, Kevin Ballard wrote:
Here's a possible solution - in $prefix/etc/ports/sources.conf, we could have a [nosync] directive after a source to tell dportsync not to sync it. Would that work for you?
It would be a good idea (in addition to the permission test).
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On 2007-05-16 03:51:25 -0400, Kevin Ballard wrote:
Ok, r25236 adds support for the [nosync] directive.
What do you mean by a permission test? dportsync already runs svn update as the owner of the working copy (in trunk).
Yes, I meant the owner test. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On 2007-05-15 15:25:29 -0400, Kevin Ballard wrote:
BTW, I've already fixed this particular issue in trunk. Port will now run svn as the user who owns the WC.
This doesn't work here: Synchronizing from file:///Users/vinc17/wd/macosx/dports Password: It shouldn't ask any password (I have a ssh-agent). The problem is that sudo probably resets the environment. You probably need to run the user's shell in a wrapper (and I'm not sure this is sufficient). A cleaner solution would be that port should do the sudo when need be. Fortunately, there's the [nosync] flag... -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
participants (6)
-
Blair Zajac
-
James Berry
-
Juan Manuel Palacios
-
Kevin Ballard
-
Ryan Schmidt
-
Vincent Lefevre