Opened 14 years ago
Closed 14 years ago
#25075 closed defect (worksforme)
postflight script sometimes overwrites conf files
Reported by: | pixilla (Bradley Giesbrecht) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | |
Keywords: | Cc: | ||
Port: |
Description
Using the disk image installer to install MacPorts 1.9.0-rc1 over the top of MacPorts current 1.8 it looks like my <prefix>/etc/macports/sources.conf was overwritten by the installer.
Installing MacPorts 1.9.0-rc1 from source over the top of MacPorts 1.9.0-rc1 <prefix>/etc/macports/sources.conf was not overwritten.
In my searches I could not determine the expected behavior.
Change History (9)
comment:1 Changed 14 years ago by mf2k (Frank Schima)
Component: | ports → base |
---|---|
Milestone: | MacPorts 1.9.0 |
comment:2 Changed 14 years ago by jmroot (Joshua Root)
comment:3 Changed 14 years ago by jmroot (Joshua Root)
I tested this, and the first time I saw the same incorrect result as you. However, subsequent installs using the pkg did the right thing. I have no idea what's going on here.
comment:4 Changed 14 years ago by jmroot (Joshua Root)
Summary: | MacPorts 1.9.0-rc1 installer may overwrite conf files → postflight script sometimes overwrites conf files |
---|
comment:5 Changed 14 years ago by pixilla (Bradley Giesbrecht)
I have been testing the pkg postflight and upgrade_sources_conf_default.tcl scripts and haven't been able to overwrite sources.conf again.
In upgrade_sources_conf_default.tcl:
if {[catch {file rename ${sourcesConf} "${sourcesConf}.mpsaved"}]} {
file rename -force ${sourcesConf} "${sourcesConf}.mpsaved_[clock seconds]"
} file rename ${tempfile} ${sourcesConf} eval file attributes ${sourcesConf} $attributes
What conditions could cause the first two rename attempts to fail? If the first two rename attempts fail does tcl continue to the third rename?
Unrelated, I noticed that InstallationCheck has this path hardcoded "/opt/local/etc/ports/dp_version".
comment:6 Changed 14 years ago by jmroot (Joshua Root)
If file rename
fails, it will throw an error. Only the first one is wrapped in a catch. I doubt that upgrade_sources_conf_default.tcl is to blame in any case, because all of my config files were overwritten the one time the installer misbehaved.
comment:7 follow-up: 8 Changed 14 years ago by pixilla (Bradley Giesbrecht)
In postflight the update_macports function tries "port -v selfupdate" and then upgrade_sources_conf_default.tcl. Since selfupdate fails without a [default] port source why not call the script upgrade_sources_conf_default.tcl which attempts to fix missing default before "port -v selfupdate"?
comment:8 Changed 14 years ago by pixilla (Bradley Giesbrecht)
Replying to brad@…:
In postflight the update_macports function tries "port -v selfupdate" and then upgrade_sources_conf_default.tcl. Since selfupdate fails without a [default] port source why not call the script upgrade_sources_conf_default.tcl which attempts to fix missing default before "port -v selfupdate"?
Nevermind. My selfupdate was failing with permission errors not because of no default. I see port selfupdate uses last source as default when there is no default in sources.conf.
comment:9 Changed 14 years ago by jmroot (Joshua Root)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Closing simply because I've never been able to reproduce this after that first time. If anyone figures out what's going on here or even just comes up with a reliable way to reproduce the problem, please reopen.
The intended behaviour is to overwrite *.conf.default and copy those to *.conf if they don't already exist. The postflight code used in the pkg should do that AFAICT. The only other thing that touches sources.conf is the script that adds a default tag if there isn't one, and it should behave identically whether run from the makefile or the postflight script.