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
Jan