dp2mp-move branch work done & merging into trunk
(same mail as before, resent with a proper subject!) Good afternoon everyone! At long last, I consider the work on my dp2mp-move branch almost 100% done, 99.99% lets say ;-) Here's a doc explaining all the implications moving to these sources has: http://trac.macports.org/projects/macports/wiki/MacPortsRenaming I'd love to get as much feedback as possible on all the renaming and moves, and an overall opinion of how things look like in a standard MacPorts installation after upgrading to this branch. I ask because this branch moves stuff like "/opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports" to "/opt/local/var/ macports/sources/rsync.macports.org/release/ports", as explained in the wiki doc, so if the chosen new paths are not what the majority regards as the best choice, corrections could be easily made before these sources are distributed to the masses. It is my intention to merge all of the branch back into trunk ASAP, after consensus is reached on best "new conventions", since people writing code against current trunk will surely have to rewrite some parts of it after this is merged, albeit changes will hopefully be small. Nevertheless, I'd very much like to minimize this negative (and quite hateful, I understand) side effect. And finally, I say "almost 100%" and not "100%" because there are still a couple of small pending things, detailed in the "Pending" section of the doc. Taking care of them shouldn't take too long at all (remaining 0.01% ;-) Regards,.... -jmpp PS: The branch mirrors trunk minus sfiera's latest commit, which we could easily merge. Therefore merging should be painless, other than the drawback detailed above. Also, branch has been tested extensively and everything works "as expected", but please do not hesitate to send me any feedback/error reports. Thanks!
Sounds great! Will this automatically affect the gcc binary names (i.e. gcc-dp-4.2 -> gcc-mp-4.2) or is a port specific change needed? Thanks, Dave
On Jun 1, 2007, at 3:45 PM, David MacMahon wrote:
Sounds great!
Thanks for the feedback! (even if it is only to tell me that things look good overall ;-) Appreciated!
Will this automatically affect the gcc binary names (i.e. gcc- dp-4.2 -> gcc-mp-4.2) or is a port specific change needed?
This is a port specific change, but one I believe mww already put in place. Nevertheless, strings in MP base sources referencing gcc-dp* have been updated to gcc-mp*, so there should be added consistency.
Thanks, Dave
Regards,... -jmpp
On Fri, Jun 01, 2007 at 02:48:21PM -0400, Juan Manuel Palacios wrote:
detailed above. Also, branch has been tested extensively and everything
Juan - can you detail specific instructions for testing the branch? I'm sure some people would be happy to help test some more.. and do you have an ETA on when you would like to merge? C. -- hail eris http://rubberduck.com/
Hey Charlie, good to see you're back! On Jun 2, 2007, at 3:53 PM, Charlie Allom wrote:
On Fri, Jun 01, 2007 at 02:48:21PM -0400, Juan Manuel Palacios wrote:
detailed above. Also, branch has been tested extensively and everything
Juan - can you detail specific instructions for testing the branch? I'm sure some people would be happy to help test some more..
Testing the branch should be no different from simply installing off of it and using the resulting MacPorts installation on a regular basis, everything should just work as expected and just as trunk/base does (there's feature parity); if it doesn't then there's a bug in one/some of my various renaming edits and I should look into it, report it to me right away! (mail, ticket assigned to me, both, whatever you prefer). I have, however, been using the branch for long already (installing ports, upgrading them, using them, etc...) and haven't experienced a single anomaly (or at least none that I haven't fixed already ;-), so I wouldn't expect anything to turn up (anything that's not also in trunk, of course). Some others have told me it's the same case for them, but anyways I always appreciate more eyes looking ;-) The only one count in which the testing protocol is particular to this branch is in the install target of the main Makefile (base/ Makefile): said target calls an 'upgrade' prerequisite that takes care of moving all of an existing MacPorts installation to the new layout outlined in the branch (installation paths, config settings, etc), so that should be carefully tested. However, this is not too difficult in itself: -) manually upgrading an existing MacPorts installation with this branch (make && make install); -) selfupdating an existing installation to this branch. Both of those upgrading methods should produce a MacPorts installation identical to one from scratch off the branch. Take a look at [1] for an idea of how things should look like. Also, installing off this branch over an already renamed MacPorts installation should work flawlessly too, so maybe you could test that as well (I've done it here myself and things look fine). The only thing I don't support is installing trunk on top of this branch and then trying to upgrade that in turn... but who in their right mind would do that....? ;-) About selfupdating to this branch, as you may have guessed it's not possible doing so off of the MacPorts rsync server, since we're still feeding the 1.4.42 tag to users. Minor manual intervention is required: -) install the branches/dp2mp-move/base/portmgr/rsync.repos file as a local rsyncd.conf file and start a local rsync server; -) point the ports.conf file to this server and to the "release/ base/" rsync module ('rsync_dir' key); -) run a local copy of the branches/dp2mp-move/base/portmgr/ mprsyncup.new script with a RELEASE_URL value of "http:// svn.macports.org/repository/macports/branches/dp2mp-move/base" (this new script fully bootstraps and populates the rsync repos); -) selfupdate. See? Minor manual intervention! ;-) Feel free to send me any suggestions/corrections you might have for the 'upgrade' target in the Makefile, it is probably the most important part of the work so it could use as much sanitizing as it can get! However, I have, again, done a lot of local testing and have progressively polished it over time, so it should be alright. Feel free to ping me if you'd like me to explain it, it's a bit involved ;-) There are some comments at the end of the target detailing some minor thoughts/doubts I still have, feel free to look into them and provide feedback if you're so inclined.
and do you have an ETA on when you would like to merge?
Unfortunately I haven't received much feedback on the branch nor on the roadmap doc at [1], so I can only assume everything is looking up and good. In fact, the only feedback I've received is two people telling me the changes look great (the new layout) and some others telling me the branch is working as expected.... so therefore I'm feeling more than ready to merge it back into trunk ASAP. The only outstanding requirement is updating the rsync server with the new modules (rsync.repos file) and the new mprsyncup script, and I'm already coordinating that with Kevin. Therefore merging should happen real soon now!
C. -- hail eris http://rubberduck.com/
Thanks for the help in testing the branch, much appreciated! Regards,... -jmpp [1] http://trac.macports.org/projects/macports/wiki/MacPortsRenaming
participants (4)
-
Charlie Allom
-
David MacMahon
-
Juan Manuel Palacios
-
Ryan Schmidt