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
4.7 KiB
4.7 KiB
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-cloneordpkg --get-selectionsto create system snapshots - Store complete package state before transactions
- Enable more comprehensive rollbacks
Why not implemented:
apt-clonemay 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
--abortto 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:
- State persistence would be the first addition for production use
- Enhanced error handling would improve user experience
- Dry-run mode would be useful for automation
- 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.