View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011056 | Taler | exchange | public | 2026-02-12 20:17 | 2026-02-16 22:39 |
| Reporter | how | Assigned To | Resolution deadline | ||
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | implementing | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | post-1.0 | ||||
| Summary | 0011056: Debian packages may break running system on upgrade | ||||
| Description | Some Debian systems may be using `unattended-upgrades` to keep packages up-to-date. When `taler-merchant` and other Taler packages are upgraded, they may require running database migrations. Yet those migrations are not automated. When such a situation occurs (also with `taler-exchange`), a previously working system will be left in a non-functioning state. When database migrations are required, they would probably be done as a post-install action: 1. make a database backup 2. run the migrations 3. restart services 4. if the previous steps fail, restore to working state and alert root The above sequence is an optimal upgrade path, but I don't know whether that matches Debian Policy. In any case, a missing migration will let the system not working, so it should at least be documented. | ||||
| Tags | packaging | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-02-12 20:17 | how | New Issue | |
| 2026-02-12 20:17 | how | Tag Attached: packaging | |
| 2026-02-16 22:39 | Christian Grothoff | Status | new => implementing |
| 2026-02-16 22:39 | Christian Grothoff | Target Version | => post-1.0 |