selfupdate to 1.0.5

[Juan Manuel Palacios]

On Jul 11, 2007, at 2:58 AM, Ryan Schmidt wrote:

> On Jul 11, 2007, at 01:33, Juan Manuel Palacios wrote:
>
>> On Jul 11, 2007, at 12:45 AM, Malcolm Fitzgerald wrote:
>>
>>> I've just done this and it suggests checking /opt/local/var/db/ 
>>> dports
>>> and move the left-overs manually. Looking in there I can see two
>>> directories, build and sources. build contains a lot of stuff and
>>> sources contains one file, _dpupdate1. Is there any reason to  
>>> move or
>>> keep these files?
>>
>> 	I put that "warning" there 'cause of the difficulty of moving the  
>> sources that live in /opt/local/var/db/dports/sources/ 
>> <name_I_never_remember__one_of_the_reasons_why_I_renamed_it ;-) 
>> >_dpupdate1, and which by the way are the ones providing the  
>> selfupdate, from underneath us while selfupdating to their new  
>> location under the much nicer and cleaner /opt/local/var/macports/ 
>> sources directory. Therefore I advice users with a concern for  
>> order to go into that evil-named directory I will not try to  
>> remember again and remove them manually, as they are unnecessary  
>> after the upgrade. Stuff under the build dir are most likely empty  
>> directories that are not pruned upon the clean action due to a bug  
>> I also corrected in 1.5.0 (yeah, I realize it's pretty clear is my  
>> own freakiness for order that motivated me to fix these things ;-).
>
> I must've overlooked that message during selfupdate, but I also  
> still have build and sources in /opt/local/var/db/dports. Can I  
> basically just delete the entire /opt/local/var/db/dports directory?


	The short answer: yes.

	The long one: my upgrade code in base/Makefile does the following  
when touching /opt/local/var/db/dports:

# Important directories inside ${localstatedir}/db/dports are moved  
to their new location, creating it first:
         [ -d ${localstatedir}/macports ] || mkdir -vp $ 
{localstatedir}/macports
         for dir in distfiles packages receipts software; do \
                 [ ! -d ${localstatedir}/db/dports/$${dir} ] || mv -v  
${localstatedir}/db/dports/$${dir} ${localstatedir}/macports ; \
         done

# Move the default ports tree to the new layout:
         [ ! -d ${localstatedir}/db/dports/sources/ 
rsync.rsync.darwinports.org_dpupdate_dports ] || { mkdir -vp \
         ${localstatedir}/macports/sources/rsync.macports.org/release  
&& mv -v \
         ${localstatedir}/db/dports/sources/ 
rsync.rsync.darwinports.org_dpupdate_dports ${localstatedir}/macports/ 
sources/rsync.macports.org/release/ports ; }


	So the only two leftovers are build and sources. I figured it wasn't  
worth moving build as it either has stuff that's already installed or  
builds that failed at some stage (and in any case, everything in that  
dir should be reproducible with the appropriate set of port  
commands). As for sources, it contains the ports tree which I move  
with the second set of instructions (and which we could always  
refetch in any case) and the MacPorts sourcs dir, which not only I  
cannot move while building MacPorts itself but also becomes obsolete  
right after the upgrade finishes.

	So, in a nutshell, yeah, you can nuke db/dports ;-)


-jmpp