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