Software Management (RPM, DNF) 2020 retrospective

[Daniel Mach]

Hi,
On behalf of RPM and DNF teams, I would like to highlight changes that 
have appeared in our packages in 2020. Thanks everyone for your bug 
reports and patches!


RPM
---

$ rpm --eval '%[0 < 1 ? "true" : "false"]'
   * Support for complex expressions and conditionals with short-circuit 
logic etc in macros via %[...] and %{expr:...}

$ rpm --eval '%[v"1.10" > v"1.2"]'
   * Rpm versions as native objects in expressions, eg v"3.1-1"

$ rpmbuild
   * Parametric macro dependency generators offer a lightning fast way 
to generate dependencies where applicable
   * Meta dependencies, eg Requires(meta) allow specifying dependencies 
without introducing ordering constraints
   * Dependency generation based on MIME types

$ rpm --rebuilddb
   * New sqlite3 backend
     * More robust than the Berkley DB backend
     * SQLite3 has also a more permissive license than the latest BDB
   * NDB backend promoted to stable
   * Support for migration (reading) from BDB databases without linking 
to BDB


DNF
---

$ dnf needs-restarting
   * Introduced the needs-restarting.d drop-in directory

$ dnf reposync
   * Fixed modularity issues, able to sync modular repos correctly

$ dnf groups-manager
   * yum-groups-manager is back
   * Upstream only, to be released in Fedora soon
   * https://github.com/rpm-software-management/dnf-plugins-core/pull/412

$ dnf module switch-to
   * Switches the module stream and also performs distro-sync on the new 
stream content

$ dnf history store/replay
   * New commands for storing a transaction and replaying it on another 
system

$ dnf system-upgrade
   * The code was refactored to use the store/replay feature in the 
background
   * Landing in Fedora now

$ dnf system-upgrade
   * Comps groups are upgraded during the system upgrades

$ dnf offline-upgrade
$ dnf offline-distrosync
   * New commands to upgrade your system on reboot


MICRODNF
--------

$ microdnf module <enable|reset|disable>
   * New commands for managing modules

$ microdnf --config
   * Microdnf reads values from dnf.conf
   * It is possible to specify a path to the config

$ microdnf --refresh
   * Force repodata refresh
   * Microdnf also honors the metadata_expire configuration option


LIBDNF
------
   * Many changes to make the DNF features available in microdnf and 
PackageKit (and Gnome Software)


DNF 5
-----
   * The goal is to remove redundant code and make sure all tools built 
on top libdnf work the same (DNF currently uses a different code path 
than microdnf and PackageKit)
   * We're behind the plan because we spent the time fixing DNF 4 stack 
instead (modularity, new features, crashes, etc.)
   * There's a COPR repo with unstable nightlies:
     * dnf copr enable rpmsoftwaremanagement/dnf5-unstable
     * dnf install microdnf5
     * dnf install python3-libdnf5 perl5-libdnf ruby-libdnf
     * WARNING: Here be dragons! The software is not ready for general 
use yet.
   * The next steps are: finish the core functionality, stabilize the 
API and make the package available in Fedora in parallel with the DNF 4 
stack

[Kamil Paral]

On Mon, Jan 18, 2021 at 9:36 AM Daniel Mach <dmach(a)redhat.com&gt; wrote:

>  $ dnf offline-upgrade
>  $ dnf offline-distrosync
>     * New commands to upgrade your system on reboot
>  
Sounds great. But I don't see those commands neither in F33 nor in Rawhide.
Am I looking wrong? Thanks.

[Vitaly Zaitsev]

On 18.01.2021 11:29, Kamil Paral wrote:
>  Sounds great. But I don't see those commands neither in F33 nor
> in 
>  Rawhide. Am I looking wrong? Thanks. 
You need to install dnf-plugin-system-upgrade package first.

-- 
Sincerely,
   Vitaly Zaitsev (vitaly(a)easycoding.org)

[Kamil Paral]

On Mon, Jan 18, 2021 at 11:33 AM Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On 18.01.2021 11:29, Kamil Paral wrote:
>  > Sounds great. But I don't see those commands neither in F33 nor in
>  > Rawhide. Am I looking wrong? Thanks.
>
>  You need to install dnf-plugin-system-upgrade package first.
>  
Thanks, Vitaly! This was mighty confusing. First, the recommended approach
by DNF itself doesn't work:

$ sudo dnf offline-distrosync
No such command: offline-distrosync. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install
'dnf-command(offline-distrosync)'"

$ sudo dnf install 'dnf-command(offline-distrosync)'
Last metadata expiration check: 3:48:58 ago on Mon 18 Jan 2021 08:39:43 AM
CET.
No match for argument: dnf-command(offline-distrosync)
Error: Unable to find a match: dnf-command(offline-distrosync)

Second, a man page for dnf-offline-* is missing even if you install the
right plugin, so it's not clear that you have it at all.

And third, why on earth is this bundled with system-upgrade, what is their
relationship? I want to perform "dnf upgrade" (or distrosync) in a safe
manner, and so doing it offline with "dnf offline-upgrade" seems natural.
So it's an offline version of upgrade/distrosync, and it's closer to those
commands than to a system-upgrade command, in my eyes.

Daniel, see above for some tips on improvements, thanks :-)

[Daniel Mach]

Dne 18. 01. 21 v 11:29 Kamil Paral napsal(a):
>  On Mon, Jan 18, 2021 at 9:36 AM Daniel Mach <dmach(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>  
>      $ dnf offline-upgrade
>      $ dnf offline-distrosync
>          * New commands to upgrade your system on reboot
>  
>  
>  Sounds great. But I don't see those commands neither in F33 nor in 
>  Rawhide. Am I looking wrong? Thanks.
>   
They're not distributed as RPMs, they're part of 
python3-dnf-plugin-system-upgrade. We should probably make their 
presence more obvious.

Created https://bugzilla.redhat.com/show_bug.cgi?id=1917378

[Marius Schwarz]

Am 18.01.21 um 09:35 schrieb Daniel Mach:
>  DNF 5
>  -----
>    * The goal is to remove redundant code and make sure all tools built 
>  on top libdnf work the same (DNF currently uses a different code path 
>  than microdnf and PackageKit)  
Can you add a new goal:

Don't use Python for it, as it it's slow on mobile devices like 
Pinephone a.s.o.


Thanks,
Marius Schwarz

[Kamil Paral]

On Mon, Jan 18, 2021 at 2:08 PM Marius Schwarz <fedoradev(a)cloud-foo.de&gt;
wrote:

>  Am 18.01.21 um 09:35 schrieb Daniel Mach:
>  > DNF 5
>  > -----
>  >   * The goal is to remove redundant code and make sure all tools built
>  > on top libdnf work the same (DNF currently uses a different code path
>  > than microdnf and PackageKit)
>
>  Can you add a new goal:
>
>  Don't use Python for it, as it it's slow on mobile devices like
>  Pinephone a.s.o.
>  
Have you tried microdnf?

[Michel Alexandre Salim]

On Mon, 2021-01-18 at 14:29 +0100, Kamil Paral wrote:
>  On Mon, Jan 18, 2021 at 2:08 PM Marius Schwarz <
>  fedoradev(a)cloud-foo.de&gt; wrote:
>  > Am 18.01.21 um 09:35 schrieb Daniel Mach:
>  > > DNF 5
>  > > -----
>  > >   * The goal is to remove redundant code and make sure all tools
>  > built 
>  > > on top libdnf work the same (DNF currently uses a different code
>  > path 
>  > > than microdnf and PackageKit) 
>  > 
>  > Can you add a new goal:
>  > 
>  > Don't use Python for it, as it it's slow on mobile devices like 
>  > Pinephone a.s.o.
>  > 
>  
>  
>  Have you tried microdnf?
>   
AIUI Marius is suggesting we highlight the increased performance of the
C++ microdnf over the original dnf?

(As is, the work is indeed already happening, it just needs better
promotion).

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/[e-mail]
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2