apt-ostree/docs/aptvsdnf.md

When we started this project we were using rust-apt.
I see now we are using
apt-pkg-native = "0.3.3"
I am just curious what features caused you to chnage.

Also, can you write up a report on how we made apt-ostree work like rpm-ostree when dnf has features not available in apt?

A modest report on features DNF has that we could have used that are missing in apt.

# DNF Library Features That May Need APT Equivalents

## Overview
When porting a Fedora tool that uses DNF libraries to Debian using `libapt-pkg7.0`, you'll need to identify which DNF-specific features the source application relies on and find equivalent implementations or workarounds.

## Core DNF Library Features to Assess

### 1. Transaction History Database
**DNF Feature:**
- Persistent SQLite database tracking all package operations
- Each transaction has unique ID with timestamp, user, and package lists
- Programmatic access to historical transactions

**Source App Might Use:**
```python
# DNF library calls
base.history.list()
base.history.get_transaction(tid)
base.history.undo_transaction(tid)
```

**APT Equivalent Considerations:**
- APT logs to flat files (`/var/log/apt/history.log`, `/var/log/dpkg.log`)
- No built-in transaction IDs or structured database
- You'd need to parse log files or implement your own transaction tracking

### 2. Atomic Transaction Operations
**DNF Feature:**
- Operations grouped as atomic units
- Built-in rollback capabilities
- Transaction state validation

**Source App Might Use:**
```python
transaction = base.transaction
transaction.install(package)
transaction.remove(package)
# All operations happen together or not at all
```

**APT Considerations:**
- APT operations are not inherently atomic
- No built-in rollback mechanism
- You'd need to implement transaction grouping yourself

### 3. File-to-Package Resolution
**DNF Feature:**
- Built-in file/capability to package mapping
- No external tools required

**Source App Might Use:**
```python
base.sack.query().filter(file="/usr/bin/htop")
```

**APT Equivalent:**
- Requires `apt-file` or parsing `Contents` files
- More complex implementation needed

### 4. Package Groups/Collections
**DNF Feature:**
- Native support for package groups
- Group metadata in repositories

**Source App Might Use:**
```python
base.group_install("Development Tools")
base.group_remove("Desktop Environment")
```

**APT Considerations:**
- APT uses "tasks" and "metapackages" instead
- Different conceptual model
- May need mapping logic

### 5. Module/Stream Support (Historical)
**DNF Feature:**
- Support for software modules with multiple streams
- Version/stream switching capabilities

**Note:** This was deprecated in recent Fedora versions, but older tools might still use it.

### 6. Repository Metadata Handling
**DNF Feature:**
- Rich metadata format (repodata)
- Dependency solver information
- Update advisory data

**Source App Might Access:**
```python
base.fill_sack()  # Load all repository metadata
base.sack.query().updates()  # Find available updates
```

**APT Considerations:**
- Different metadata format (`Packages`, `Release` files)
- May need format conversion or abstraction layer

### 7. Plugin System Integration
**DNF Feature:**
- Extensive plugin architecture
- Hooks for pre/post operations

**Source App Might Use:**
```python
# Plugin hooks
dnf.plugin.post_transaction()
dnf.plugin.pre_transaction()
```

**APT Considerations:**
- Limited plugin system
- May need custom hook implementation

## Implementation Strategy Considerations

### Direct Feature Mapping
Some features have reasonable APT equivalents:
- **Package installation/removal** - Direct mapping
- **Dependency resolution** - APT's resolver is capable
- **Repository management** - Similar concepts

### Features Requiring Workarounds
These will need custom implementation:
- **Transaction history** - Parse APT logs or implement tracking
- **Rollback operations** - Custom state management
- **File-to-package mapping** - Integrate apt-file or build index

### Features That May Not Apply
- **RPM-specific operations** - May not be relevant for DEB packages
- **Module streams** - Debian doesn't use this model
- **Group installations** - Different paradigm in Debian

## Practical Assessment Questions

To identify what you'll actually need to implement:

1. **What specific DNF library calls does the source application make?**
2. **Does it use transaction history features?**
3. **Does it rely on package groups or modules?**
4. **How does it handle repository metadata?**
5. **Does it use DNF's plugin system?**
6. **What error handling does it expect from DNF operations?**

## Recommendation

I'd suggest:
1. **Audit the source code** for actual DNF library usage
2. **Create an abstraction layer** that maps DNF calls to APT equivalents
3. **Identify features that need custom implementation** vs. direct mapping
4. **Test with representative use cases** to ensure behavior matches

Would you be able to share what specific DNF library features the source application actually uses? That would help provide more targeted guidance on the APT implementation approach.