patch to fixup existing uninstall implementation

[david.osguthorpe@…]

This patch fixes up the pre-existing pkg_uninstall implementation so that it works

[blb@…]

Since pkg_uninstall is not actually used, perhaps it would be best to simply delete its handling. Especially as it seems to be a bit messy in usage since as you say in that comment, a number of variables aren't available.

[david.osguthorpe@…]

Replying to blb@…:

Since pkg_uninstall is not actually used, perhaps it would be best to simply delete its handling. Especially as it seems to be a bit messy in usage since as you say in that comment, a number of variables aren't available.

I added this because someone was asking for such a procedure on the mailing list recently - Im not sure what you mean by pkg_uninstall is not actually used - you mean that no Portfile defines it - it would only be defined in Portfiles - not in base itself

Well it does actually enable you to do something at uninstall - I was just pointing out that its run in a different context to the rest of the Portfile - its actually probably not useful that destroot is defined - by uninstall time for a normal port install the whole work directory would have been deleted at the install stage in any case - Ive just never sorted out in detail what variables are defined - but theres enough information to operate explicitly on paths you know about - which is what I am using it for (since 1.3/4 odd)

[blb@…]

Replying to david.osguthorpe@…:

I added this because someone was asking for such a procedure on the mailing list recently - Im not sure what you mean by pkg_uninstall is not actually used - you mean that no Portfile defines it - it would only be defined in Portfiles - not in base itself

Right, I didn't find any Portfiles which actually define pkg_uninstall.

Well it does actually enable you to do something at uninstall - I was just pointing out that its run in a different context to the rest of the Portfile - its actually probably not useful that destroot is defined - by uninstall time for a normal port install the whole work directory would have been deleted at the install stage in any case - Ive just never sorted out in detail what variables are defined - but theres enough information to operate explicitly on paths you know about - which is what I am using it for (since 1.3/4 odd)

True, and having a pre/post-deactivate and uninstall step is definitely something which would be useful, but I'm not sure if this is the way to do it. It's correct that ${destroot} wouldn't be useful during uninstall, but what other bits may be? I think the better solution is to allow deactivate and uninstall hooks in the Portfile and they can be run by port just like with other, similar steps. I think my primary issue with it is that this method is so different than the rest of the way Portfiles work, though it does have the advantage of being implemented...

[david.osguthorpe@…]

Right, I didn't find any Portfiles which actually define pkg_uninstall.

of course as the current implementation does not work its not surprising its not used

True, and having a pre/post-deactivate and uninstall step is definitely something which would be useful, but I'm not sure if this is the way to do it. It's correct that ${destroot} wouldn't be useful during uninstall, but what other bits may be? I think the better solution is to allow deactivate and uninstall hooks in the Portfile and they can be run by port just like with other, similar steps. I think my primary issue with it is that this method is so different than the rest of the way Portfiles work, though it does have the advantage of being implemented...

I dont know what the basis of the original programmers implementation was - but it is consistent with the rest of the current uninstall proc which also totally ignores Portfile - it deletes files based on whats in the registry - and its executed directly

ah - I think Ive just figured out a good reason for this approach - suppose you deactivate a port - this still leaves the files in the registry - now you update the Portfile and change versions etc. and if it had an uninstall phase you change that - now how do you uninstall that older deactivated version correctly? (which of course you were leaving around in case your new version didnt work) - also explains the current uninstall approach of deleting files based only on whats in the registry and why its independent of the whole Portfile fetch-install phases

[blb@…]

Replying to david.osguthorpe@…:

ah - I think Ive just figured out a good reason for this approach - suppose you deactivate a port - this still leaves the files in the registry - now you update the Portfile and change versions etc. and if it had an uninstall phase you change that - now how do you uninstall that older deactivated version correctly? (which of course you were leaving around in case your new version didnt work) - also explains the current uninstall approach of deleting files based only on whats in the registry and why its independent of the whole Portfile fetch-install phases

This is also a problem if actions should be taken for deactivate, if you have multiple versions installed; again, with it only in the Portfile (and said Portfile only exists in the source repository location) then it's deactivate actions are also from the latest version.

The way to do this for activate (if reactivated later), deactivate, and uninstall is to store either each in some location like the pkg_uninstall here or to keep the correct Portfile around as it was when that version was installed. If #19458 happens that keeps the Portfile with the image so it could be used in such cases...

[jmr@…]

Applied in r64640.