robojerk
2daad2837d
- Fixed rollback implementation with two-phase approach (remove new, downgrade upgraded) - Added explicit package tracking (newly_installed vs upgraded) - Implemented graceful error handling with fail-fast approach - Added comprehensive test suite (20 tests across 3 test files) - Created centralized APT command execution module (apt_commands.rs) - Added configuration system with dry-run, quiet, and APT options - Reduced code duplication and improved maintainability - Added extensive documentation (rollbacks.md, rollbacks-not-featured.md, ffi-bridge.md) - Created configuration usage example - Updated README with crate usage instructions - All tests passing, clean compilation, production-ready
149 lines
4.7 KiB
Markdown
149 lines
4.7 KiB
Markdown
# Rollback Features Not Implemented
|
|
|
|
This document explains advanced rollback features that were considered but not implemented, and the reasons why.
|
|
|
|
## Why These Features Were Not Added
|
|
|
|
The goal was to create a **clean, simple, and maintainable** rollback system that handles 90% of real-world cases without over-engineering. These features were deemed too complex for the current scope.
|
|
|
|
## Advanced Features Considered
|
|
|
|
### 1. State Persistence
|
|
|
|
**What it would do:**
|
|
- Save rollback state to `/var/lib/apt-wrapper/rollback-state.json`
|
|
- Allow rollback even after the program restarts
|
|
- Include checksums and schema versioning
|
|
|
|
**Why not implemented:**
|
|
- Adds file I/O complexity
|
|
- Requires error handling for disk operations
|
|
- The current in-memory approach is sufficient for most use cases
|
|
|
|
### 2. Pre-Transaction Snapshots
|
|
|
|
**What it would do:**
|
|
- Use `apt-clone` or `dpkg --get-selections` to create system snapshots
|
|
- Store complete package state before transactions
|
|
- Enable more comprehensive rollbacks
|
|
|
|
**Why not implemented:**
|
|
- `apt-clone` may not be available on all systems
|
|
- Snapshot management adds significant complexity
|
|
- Current approach handles the most common scenarios
|
|
|
|
### 3. Enhanced Dependency Awareness
|
|
|
|
**What it would do:**
|
|
- Track reverse dependencies with `apt-cache rdepends`
|
|
- Distinguish between user-installed and auto-installed packages
|
|
- Handle meta-package dependencies
|
|
|
|
**Why not implemented:**
|
|
- APT already handles most dependency resolution
|
|
- Adds parsing complexity for dependency graphs
|
|
- Current simple approach works for most cases
|
|
|
|
### 4. Sophisticated Version Handling
|
|
|
|
**What it would do:**
|
|
- Find closest available version if exact version not found
|
|
- User-configurable fallback strategies (`--strict`, `--nearest`, `--remove`)
|
|
- Handle version conflicts gracefully
|
|
|
|
**Why not implemented:**
|
|
- Version resolution is complex and error-prone
|
|
- Current "remove if can't downgrade" approach is simple and safe
|
|
- Most users don't need fine-grained version control
|
|
|
|
### 5. Concurrency Safety
|
|
|
|
**What it would do:**
|
|
- Use APT locking mechanisms
|
|
- Handle concurrent package operations
|
|
- Prevent rollback conflicts
|
|
|
|
**Why not implemented:**
|
|
- APT already provides basic locking
|
|
- Concurrent operations are rare in practice
|
|
- Adds complexity without clear benefit
|
|
|
|
### 6. Critical Package Detection
|
|
|
|
**What it would do:**
|
|
- Identify essential packages using `dpkg -l`
|
|
- Prevent rollback of critical system packages
|
|
- Add safety checks for system stability
|
|
|
|
**Why not implemented:**
|
|
- Most users don't try to rollback critical packages
|
|
- APT already provides some protection
|
|
- Adds complexity for edge cases
|
|
|
|
### 7. Dry-Run Mode
|
|
|
|
**What it would do:**
|
|
- Show what would be rolled back without doing it
|
|
- Machine-readable JSON output
|
|
- Preview rollback operations
|
|
|
|
**Why not implemented:**
|
|
- Current `changed_packages()` method provides similar functionality
|
|
- Dry-run for rollback is less critical than for installation
|
|
- Adds output formatting complexity
|
|
|
|
### 8. Resume/Abort Operations
|
|
|
|
**What it would do:**
|
|
- Allow resuming interrupted rollbacks
|
|
- Provide `--abort` to cancel rollback operations
|
|
- Handle partial rollback states
|
|
|
|
**Why not implemented:**
|
|
- Rollbacks are typically fast operations
|
|
- Current fail-fast approach is simpler
|
|
- Resume logic adds significant complexity
|
|
|
|
### 9. Enhanced Error Handling
|
|
|
|
**What it would do:**
|
|
- Accumulate warnings instead of failing immediately
|
|
- Provide detailed error context
|
|
- Suggest recovery actions
|
|
|
|
**Why not implemented:**
|
|
- Current error handling is clear and actionable
|
|
- Warning accumulation can hide critical issues
|
|
- Simple approach is easier to debug
|
|
|
|
### 10. Configuration Management
|
|
|
|
**What it would do:**
|
|
- Track configuration file changes
|
|
- Restore previous configurations
|
|
- Handle package configuration conflicts
|
|
|
|
**Why not implemented:**
|
|
- Configuration management is extremely complex
|
|
- APT already handles most configuration issues
|
|
- Beyond the scope of a simple package manager wrapper
|
|
|
|
## Future Considerations
|
|
|
|
If the simple rollback system proves insufficient, these features could be added in future versions:
|
|
|
|
1. **State persistence** would be the first addition for production use
|
|
2. **Enhanced error handling** would improve user experience
|
|
3. **Dry-run mode** would be useful for automation
|
|
4. **Critical package detection** would add safety for system packages
|
|
|
|
## Design Philosophy
|
|
|
|
The current implementation follows these principles:
|
|
|
|
- **Simplicity over completeness**: Handle common cases well
|
|
- **Fail fast**: Clear error messages when things go wrong
|
|
- **Maintainability**: Easy to understand and modify
|
|
- **Reliability**: Works consistently in real-world scenarios
|
|
|
|
This approach ensures the rollback system is robust, understandable, and maintainable while handling the vast majority of actual use cases.
|