Provide better output on toltecctl uninstall

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.

[Eeems]

• Provide output right at the end if a removal fails due to a preremove script. That way, the user can double-check the output to see if there is something bad. For example, kernelctl failed to revert to the stock kernel.
• Make changes to toltecctl to get closer to allowing the installation to be somewhere other than /opt, not that entware supports that yet.
• Make toltecctl uninstall handle unexpected states like partial uninstall a lot better.
• Backup toltecctl on uninstall to continue allowing users to uninstall if something goes wrong.
• Fix issues with installdepends not properly being set for several packages that caused them to be removed after their dependencies were removed, thus breaking uninstall.

[rM-self-serve]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

[Eeems]

I created a test package that will fail during preremove.
Do you have any tips on restoring /opt after uninstalling?

Uninstall removes /opt, which is actually /home/root/.entware. you will have to install again with bootstrap. If you want to avoid doing so, you can copy the .entware folder before doing the uninstall, rename the copy to .entware after uninstalling and then re-enable.

[Havner]

completed vs complete, wrong variable names

[Eeems]

You seem to be reviewing an outdated version, this is $complete for me when I look

[Havner]

Ok, I'm reviewing patches in order, not a full diff. I'm more used to a workflow where a PR is force updated instead of incremental patches and a squash afterwards.

[Havner]

Also I think there is operator order issue here:

$ export VAR1=true
$ export VAR2=true
$ export VAR3=true
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ export VAR2=false
$ if ! $VAR1 && $VAR2 && $VAR3; then echo failed; fi
$ if ! ($VAR1 && $VAR2 && $VAR3); then echo failed; fi
failed

[Eeems]

Since they are declared as local it could be that they aren't working as expected. Although when I tested this originally it was working as I expected.

[Havner]

I don't think local makes any difference here, ! has higher priority than && hence it applies only to VAR1 and from the look of it you wanted to apply it to the whole expression (V1 && V2 && V3)

[Eeems]

I would have wrapped it in ( and ) if I was trying to apply it to all of them, I'm checking if not complete, and success and clean. success/clean are true by default and get changed to false when something else handles reporting an error.

[Havner]

Ah, ok then. From reading the code it looked to me like you are looking for a failure scenario (e.g. at least one of those vars is false).

[Eeems]

In this case, I'm only wanting to handle the error if the error handler is triggered and we did not complete the uninstall, and nothing set success or clean to false due to their own error handling.

It is less than ideal, thus the extra comments on the variable declarations. I couldn't really come up with a cleaner way to handle this with the limitations bash has on error handling.

[Havner]

I would have to analyze this fully to check the logic completely. I'm too tired now.

What I did find though is that you make a dep between clean and success so checking both in this line might be at least redundant.

https://github.com/toltec-dev/toltec/blob/Eeems-patch-10/package/toltec-bootstrap/toltecctl#L885

But I'm not able to check the logic fully now.