Managing non RPM software in DNF5

[j-mracek]

DNF is capable of installing only RPMs, RPMs from comps groups and module profiles. But Gnome Software is capable of installing Flatpaks and users do not see a difference between installing RPM and Flatpak. If DNF is supposed to be a centralized point for software management from the command line then we have to think about supporting alternative ways how software is delivered. The feature might be also used for already implemented comps groups and modules to make them optional.

Questions to proposal

1. When I type dnf install firefox shall dnf install firefox regardless of type of distribution (RPM, Flatpak, or other types)?
   Do we need to provide a configuration option to set a preference order (prefer Flatpaks over RPMs)
2. Shall dnf provide installation or other operations for particular type of software using following pattern or other pattern?
   dnf <type> install firefox
dnf flatpak install firefox
dnf rpm install firefox
dnf flatpak upgrade
3. When I type dnf upgrade shall dnf upgrade all supported software type (RPM, Flatpaks, ...)?
4. When I type dnf repoquery shall dnf show only available RPMs?
5. When I type dnf list shall dnf show only records related to RPMs?
6. When I type dnf history shall dnf show only records related to RPMs or also to other software types?
7. When I type dnf group install group1 and the group definition contains

<group>
   <id>group1</id>
   <name>Group One</name>
   <packagelist>
     <packagereq type="mandatory">firefox</packagereq>
   </packagelist>
 </group>

Shall dnf install firefox from a flatpak or skip it when rpm firefox is not available?

8. Do we need to add a Flatpak type to comps groups?

<group>
   <id>group1</id>
   <name>Group One</name>
   <packagelist>
     <packagereq type="mandatory" distribution=”flatpak”>firefox</packagereq>
   </packagelist>
 </group>

Note: Comps group format is not versioned, therefore additional keywords or sections, might be problematic (Related components - Satellite, Pulp, Libcomps, Libsolv).

Requirements

• DNF5 must be installable without a support of alternative software types
  • Allows optimizing DNF5 for a particular distribution or a use case.
    • Some distribution does not use some software types (modules, comps groups) or some dependencies are not available (libcomps, libmodulemd)
    • Allow a minimal install size in containers
  • Support of alternative software types must be modifiable during runtime
    • Build time options does not provide enough flexibility
• DNF5 must not re-implement a support of alternative software types
• Use libraries and only create a wrapper around it and add new commands or options to DNF5

[ppisar]

1. Yes (dnf install firefox to use flatpak) because "users do not see a difference between installing RPM and Flatpak". If we provide an explicit way of choosing the form (RPM vs. flatpak), then then the globally configurable preference might not be so helpful. I don't think distributions will maintain both forms in production quality and let user to choose between them.
2. Yes (operations on particular type). Especially installation. Very helpful for developers testing their packaging outputs before throwing them on their users. Less meaningful if one form could mimic another form (i.e. installed Flatpak firefox would synthesize firefox RPM Provide and /usr/bin/firefox file so that other RPM packages requiring firefox would keep working). Another pattern is "dnf install rpm:///firefox flatpak:///firefox"
3. Yes (dnf upgrade for all). It's the same as "dnf install".
4. Probably no. (dnf repoquery). repoquery is very specific to RPM. Most of it would not make no sense for Flatpaks.
5. I don't know. I never got an idea of "dnf list".
6. Yes (history). The same as install and upgrade.
7. Groups should install Flatpaks. Desktop installations will want to preinstall many graphical applications which Gnome team wants to move to Flatpaks. At the end, it's just a different form of "dnf install ...".
8. If groups without explicit flatpaks were to difficult for libsolv etc., groups could be extended with specific <flatpaklist/> or <flatpakreq/> elements. I don't like the "distribution" attribute. Especially because current implementations would ignore the attribute and keep handling it as an RPM package.

Support of alternative software types must be modifiable during runtime. Build time options does not provide enough flexibility

I think it's exactly the opposite. Distribution not interested in modules will want to exclude libmodulemd from build-time dependencies.

[jan-kolarik]

My points of view:

1. I would be for creating a configuration option to setup preferring a specific content type, because there are numerous of packages provided in several content types. If installed package is not of the preferred type, it should be explicitly mentioned to the user.
2. Yes, that seems handy!
3. Yes.
4. Just RPM packages.
5. I'd output all packages of various content types.
6. All items from transactions should be displayed.
7. This would depend on the configuration option. I'd be for: check preferred content type is available, if not then try to install any other content type.
8. I wouldn't extend the comps format.

[ericcurtin]

Could be worth adding fwupd to the list of non-rpm things that can be upgraded, aka:

sudo fwupdmgr refresh --force
sudo fwupdmgr update

[cgwalters]

There's a ton to say here...one relevant prior art here is how Ubuntu changed their dpkg to suggest installing snaps I believe.

My high level thought is that it makes sense to do some superficial things...for example, some operating systems may want to ship things only as flatpaks, and it'd definitely be helpful for us to at least detect this an provide a useful message instead of just saying "package not found".

But there's a giant array of details in having dnf update try to update flatpaks too by default. I can see it being valuable again to have some informative bits at the end of a "dnf update" saying e.g. "3 flatpaks are installed, use flatpak update to update".

It's really hard to hide all the implementation detail differences; there's a ton. To give just one, there is flatpak ps - it's aware of the version of running apps to help describe state like "new app image is fetched, but not running". which is not true for dnf today. (But that possibility is also there for bootc note).

Could be worth adding fwupd to the list of non-rpm things that can be upgraded

Right that's another example...fwupd inherently operates on the next boot, and I think we are going to put ourselves into some surprising situations if typing dnf update suddenly starts changing the next boot by default.

I'd again argue that it makes sense to have something informative, but wrapping fully gets into a whole world of complexity.

[j-mracek]

I agree that implementation of the support non rpm content will be difficult and it will require to keep dnf standard, like when you request an upgrade, command must show what is going to be upgraded and wait until user confirm the request, performing the operation transparently (callbacks), and providing a result of the transaction for a summary at the end.