DNF replacing yum: fedup?

Will Woods wwoods at redhat.com
Mon Jan 26 22:52:36 UTC 2015


On Mon, 2015-01-26 at 13:26 -0800, Adam Williamson wrote:
> I note the ReplaceYumWithDnf Change page:
> 
> https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
> 
> says nothing about fedup. However, fedup uses yum:
> 
> [adamw at adam fedup (master %)]$ grep -R yum * | wc -l
> 74
> 
> Has this been considered yet?

Oh sure. I consider lots of things. I am large, I contain multitudes.

> Should porting fedup to dnf be in the scope of this Change?

If you want upgrades to work without yum, yes.

> Does that affect its practicability for F22?

That depends on how much help you expect to be able to find for that
porting effort, since I haven't ever worked with DNF.

It's not actually that complicated; 90% of what fedup does with yum
would be equivalent to a DNF command like:

  dnf --releasever=22 upgrade --testonly \
      --pkglist=/var/lib/system-upgrade/package.list

which would:

  * download (and verify) updates for all packages using the F22 repos,
  * run a test transaction of those updates, and report errors, and
  * write a list of packages used in the update to the named file[1].

After that, you'd just need something like a 'treeinfo' command[2] that
could handle a command line:

  dnf --releasever=22 treeinfo download kernel upgrade.img

Which would:
* download .treeinfo.signed from the configured repo(s)
* verify it using the RPM trusted key(s)[3]
* use that to download/verify the items listed (kernel, upgrade.img)

That's about it. Everything else is outside the scope of dnf.

(As an aside, PackageKit should also support these operations, so we can
use PackageKit to make a Upgrade GUI Thing.)

If anyone from the DNF/PackageKit teams wants to talk more about getting
these things working, I'm happy to discuss the requirements in more
detail. I'll also be at DevConf in Brno next weekend if anyone wants to
discuss it in person.

-w

[1] This is so that upgrade.img knows which packages to install after we
reboot. Alternately we'd just need a guarantee that every RPM file under
$SOMEDIR is part of the upgrade transaction, and then fedup could
construct package.list itself.
[2] For more information about .treeinfo, see
https://github.com/wgwoods/fedup/blob/master/fedup/treeinfo.py
[3] The F22 key(s) get automatically trusted during the process of
verifying the F22 packages, so after that you can verify F22 stuff
against the RPM keyring.



More information about the devel mailing list