Software Management call for RFEs

[John Reiser]

> Therefore I call to you, consumers of our products (dnf, yum and 
> rpm): what are the changes that you would like to see in the foreseeable 
> future (say 2-3 years) and why would you like to see them (what would they 
> help you with)?

Feature: facility for atomic upgrade of an entire set of packages.
Either all succeed, or none succeed; and in bounded time.
This would help with maintaining consistent development environments:
gcc+binutils+gdb, etc.  In practice it matters (especially for
cross-platform development, and reproducing bugs reported by remote machines),
even if in theory it shouldn't.


Feature: faster performance.
rpm install/upgrade is 2X too slow.  yum install/upgrade is 3X too slow.
"The disk" should be 100% busy from start to finish, and at all times
each CPU core should be either busy or waiting for "the disk".
Specific goal: a full install of 1200 packages totaling 1.5GB of .rpm
expanding to 3.6GB on the target takes five minutes on a common desktop/laptop.
This averages 5MB/s input ("4X" DVD, "32X" CD), and 12MB/s output.

Speed rpm install/upgrade by parallel and pipeline:
  Topological sort into tiers.  tier 0: no dependencies; tier K+1: dependencies
    only in tiers 0..K.
  Within a tier: all packages are independent, thus can be done in parallel.
  Within a package: all of the reads that occur before the first write
    can be done in parallel with *ANY* other package, regardless of dependencies.
    Thus parsing and decompression of .rpm into memory (or a unique staging
    directory within a tmpfs) can be parallel regardless of dependencies.
    Perhaps writes to database must be restricted to one package at a time (despite
    logical parallelism within a tier), but this can be pipelined with the read phase.

Speed yum install/upgrade by speeding rpm, plus distribute "Verifying ..."
  and symlink data-basing out of a separate pass and into the rpm pipeline.

--