Opened 15 years ago
Closed 14 years ago
#20626 closed enhancement (duplicate)
patch to allow for proper functioning of pre-/post- install/uninstall/activate/deactivate procs
| Reported by: | david.osguthorpe@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | base | Version: | |
| Keywords: | Cc: | ||
| Port: |
Description
The current implementation of pre-/post- procs for install/uninstall/activate/deactivate has many issues. pre-/post- procs dont exist for deactivate/uninstall pre-/post- activate procs are not run when port activate is called directly - only from the indirect internal munging of a port install call pre-/post- activate procs are not run for non-image installs even though they perform actions such as starting daemons
with this patch pre-/post- procs are stored in the registry and hence are versioned so when a specific version is re-activated (or deactivated) that versions specific procs are run activate/deactivate are treated as a sub-phase of install/uninstall rather than separate phases after install/before uninstall (which makes procs for non-image installs work and removes the internal munging of port install to port activate) (variant pre-/post- install/uninstall/activate/deactivate procs are treated as for current install/activate variants)
The changes required are relatively clean hence I thought it would be useful to have the patch available before other changes etc. for 1.8.0 might destroy them
TODO: What is not implemented yet is storing procs with the archive for archive mode (which is not the default any more but important for me because I use it)
Attachments (1)
Change History (5)
Changed 15 years ago by david.osguthorpe@…
| Attachment: | patch-procs.diff added |
|---|
comment:1 follow-up: 2 Changed 15 years ago by jmroot (Joshua Root)
| Version: | 1.7.0 |
|---|
comment:2 Changed 15 years ago by david.osguthorpe@…
Replying to jmr@…:
I'd rather make these into real targets than replicate all this infrastructure. Also, it might be better to wait until after the images-and-archives branch is merged.
I dont think this is possible - what would deactivate/uninstall depend on? they cannot depend on install or activate (think what would happen if you then said uninstall a target that was not installed - it would install the target just to uninstall it - so you would always need a special check to detect that the target was already activated/installed first) do you like the internal munging of port install to port activate? also if port activate is the final phase the instructions for macports should read: to install a port with macports use the command port activate
they also cannot be the same as install targets as deactivate/uninstall are not performed in the same environment - there is no work path, no destroot etc. (this is also true of activate - if you do install->deactivate->activate that last activate no longer has the work path/destroot etc. environment - probably why currently on that last activate no pre-/post- procs are run) in addition you would have to get the whole target system to somehow read the old version of the Portfile (do you know how to do this? - I thought about this but it looked as though it would require far more modifications than this working implementation) when will the image/archive branch be merged?
comment:4 Changed 14 years ago by jmroot (Joshua Root)
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
I'd rather make these into real targets than replicate all this infrastructure. Also, it might be better to wait until after the images-and-archives branch is merged.