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