#21794: dryrun and archivemode issue ----------------------------------------+----------------------------------- Reporter: david.osguthorpe@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 1.8.0 Keywords: | Port: ----------------------------------------+----------------------------------- with archivemode set to yes doing port -d -y install in a directory works but running this command a second time gives the error Error: Requested variants "+darwin" do not match original selection "". Please use the same variants again, perform 'port clean VTK' or specify the force option (-f). this appears to be because the statefile has been written with target: org.macports.unarchive but no variants have been set doing port -d clean fixes this - by cleaning the statefile (although note that the creation of work directories/statefiles also occurs for dependents which are not cleaned) the explanation is as follows the current dryrun implementation actually creates files/directories it creates work directories and a null statefile because in target_run at the begining the open_statefile is executed which creates the work directory and statefile if {[ditem_key $ditem state] != "no"} { set target_state_fd [open_statefile] } with archivemode set to yes this adds unarchive as a dependent again in target_run there is a call to the init proc of the target which is actually run in dryrun mode if {[ditem_contains $ditem init]} { set result [catch {[ditem_key $ditem init] $targetname} errstr] } this is not protected by the dryrun option so is executed in package1.0/portunarchive.tcl the init proc will write to the statefile if it needs to skip the unarchive main - which it does if there is no archive - which in general there will be for a dryrun # Skip unarchive target by setting state if {$skipped == 1} { write_statefile target "org.macports.unarchive" $target_state_fd } this non-null statefile which has not had the variants set correctly then causes the second run of port -d -y install to fail a possible fixup is to protect the portunarchive write by the dryrun option - and indeed this does prevent the error described initially (a null statefile doesnt cause the problem) however its not clear to me why either the statefile is initially written or the init proc is being run in dryrun mode not doing these would also fix the problem ( the portarchive init proc also attempts to write the statefile but this will not be done normally because this is not skipped as no destroot has been created in dryrun mode) -- Ticket URL: <http://trac.macports.org/ticket/21794> MacPorts <http://www.macports.org/> Ports system for Mac OS