> 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.
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
