Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable optional rollback functionality when upgrading packages #25202

Open
embray opened this issue Apr 18, 2018 · 4 comments
Open

Enable optional rollback functionality when upgrading packages #25202

embray opened this issue Apr 18, 2018 · 4 comments

Comments

@embray
Copy link
Contributor

embray commented Apr 18, 2018

With #25139 it becomes possible to fully uninstall all files associated with a package, which is done before upgrading that package to a new version.

This would just as easily allow creating a backup of the package by moving its files to a temporary location rather than deleting them. If the package upgrade fails, the old version could then be restored.

One could even imagine keeping backups that can be restored even after a seemingly successful upgrade (e.g. the upgrade succeeds building, but causes runtime regressions). One could easily get carried away with something like this though and end up re-implementing hashdist (which honestly wouldn't be such a bad thing to have built into Sage...).

But to keep things focused I think this ticket should just consider rollback on build failures to start with.

Depends on #25139

Component: build

Issue created by migration from https://trac.sagemath.org/ticket/25202

@embray embray added this to the sage-8.3 milestone Apr 18, 2018
@jdemeyer
Copy link

Replying to @embray:

One could easily get carried away with something like this though and end up re-implementing hashdist (which honestly wouldn't be such a bad thing to have built into Sage...).

Just FYI in case you didn't know: our release manager is one of the main contributors to hashdist. The project looks pretty dead though: the last commit on github was 2 years ago.

@embray
Copy link
Contributor Author

embray commented Jul 13, 2018

comment:2

Replying to @jdemeyer:

Replying to @embray:

One could easily get carried away with something like this though and end up re-implementing hashdist (which honestly wouldn't be such a bad thing to have built into Sage...).

Just FYI in case you didn't know: our release manager is one of the main contributors to hashdist. The project looks pretty dead though: the last commit on github was 2 years ago.

I know. I tried using it a while ago to build Sage on Cygwin and had some problems due to a lack of Cygwin-specific patches for a number of dependencies that needed to be ported over. Other than that, a few other details I had quibbles with, the way it works makes a lot of sense and I'm surprised Volker didn't push more to get Sage using it. I would have...

@embray embray modified the milestones: sage-8.3, sage-8.4 Jul 18, 2018
@embray embray modified the milestones: sage-8.4, sage-8.5 Oct 28, 2018
@embray
Copy link
Contributor Author

embray commented Dec 28, 2018

comment:5

Retargeting some of my tickets (somewhat optimistically for now).

@embray embray modified the milestones: sage-8.5, sage-8.7 Dec 28, 2018
@embray
Copy link
Contributor Author

embray commented Mar 25, 2019

comment:6

Removing most of the rest of my open tickets out of the 8.7 milestone, which should be closed.

@embray embray removed this from the sage-8.7 milestone Mar 25, 2019
@embray embray added the pending label Mar 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants