apt-ostree/docs/.old/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:

# 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:

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:

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:

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:

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:

# 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.