Software Management call for RFEs

Jan Zelený jzeleny at
Thu May 23 11:14:41 UTC 2013

On 22. 5. 2013 at 08:38:35, John Reiser wrote:
> > 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.

I can recommend you the yum-fs-snapshot plugin for that. Doing snapshots is 
currently the only feasible way to ensure atomicity of multi-package 
transactions. It's important to note that restrictions for this don't come 
from rpm but rather from kernel (e.g. filesystem features).

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

I'm pretty sure we don't have the manpower for this sort of optimization but 
we'll take it into consideration.

Thank you

More information about the devel mailing list