Changes between Version 8 and Version 9 of MacPortsRenaming
- Timestamp:
- Jun 6, 2007, 7:08:21 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MacPortsRenaming
v8 v9 1 Upon migrating away from the defunct OpenDarwin community, the MacPorts project also changed its name from the long standing "DarwinPorts", in order to reflect its aim to refocus support solely on Mac OS X.1 Upon migrating away from the defunct OpenDarwin community, the MacPorts project also changed its name from the long standing "DarwinPorts", in order to better reflect its aim to refocus support solely on Mac OS X. 2 2 3 3 This change brought about great mixture between the old and new names at various aspects of the project, like chosen installation paths, internal routines naming and many others, as every naming decision up to the point of migration had naturally been based on the old project name. When first moving to our new name great effort was put into updating most of the user visible stuff to the implied new namespace, but many "under the hood" things were left behind in the old namespace due to time constraints in getting MacPorts 1.4 out the door, including every single installation path. … … 30 30 }}} 31 31 32 `selfupdate` and `sync` routines in this branch, however, have been upgraded to work with a much more flexible and cleaner skeleton: sources are now fetched into a `/opt/local/var/macports/sources/<server>/<rsync_module>` hierarchy. This may not seem like much at first, but closer inspection reveals this approach allows room to grow in every custom way users might need ,while also preserving a sense of order. Default paths will now look like:32 `selfupdate` and `sync` routines in this branch, however, have been upgraded to work with a much more flexible and cleaner skeleton: sources are now fetched into a `/opt/local/var/macports/sources/<server>/<rsync_module>` hierarchy. This may not seem like much at first, but closer inspection reveals this approach allows room to grow in every custom way users might need while also preserving a sense of order. Default paths will now look like: 33 33 34 34 {{{ … … 45 45 `trunk/base` being the corresponding rsync module in this case that would come to replace the old and confusing `/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate/base` directory. 46 46 47 This new structure also allows us to distribute a new and custom ports tree under an entirely different rsync module if we so wish, while still preserving order. An example of this would look like, for a ports tree with Portfiles still in testing:47 This new structure also allows us to distribute a new and custom ports tree under an entirely different rsync module if we so wish, while still preserving order. An example of this would look like, for a hypothetical ports tree with Portfiles still in testing: 48 48 49 49 {{{ … … 59 59 }}} 60 60 61 Furthermore, an upgrade target in the [source:branches/dp2mp-move/base/Makefile.in main Makefile] takes care of moving everything that's "old" in an existing MacPorts installation into its new location before regular installation begins. Among these moves there are a set of `sed` rules that act on existing configuration files to upgrade them to the new conventions. For the new `macpors.conf` file, these are:61 An upgrade target in the [source:branches/dp2mp-move/base/Makefile.in main Makefile] takes care of moving everything that's "old" in an existing MacPorts installation into its new location before regular installation of the new sources begins, as detailed in the moves above. Also, among these moves there are a set of `sed` rules that act on existing configuration files to upgrade them to the new conventions. For the new `macpors.conf` file, these are: 62 62 63 63 * new default path up to the configuration files is inserted, `/opt/local/etc/ports ---> /opt/local/etc/macports`;