On 03/22/2018 01:51 PM, Nico Kadel-Garcia wrote:
On Thu, Mar 22, 2018 at 10:52 AM, John Reiser <jreiser@xxxxxxxxxxxx> wrote:
On 03/22/2018 05:40 AM, Daniel Mach wrote:
We are pleased to announce that development of DNF 3 has started. This
version is focused on performance improvements, new API and consolidating
the whole software management stack.
How does RPM fit into DNF's view of "the whole software management stack"?
RPM is a slug (moves very slowly): no parallelism (at any point all packages
with no remaining predecessors could be updated/installed in parallel),
not even manually pipelined (decompress to memory, manipulate filesystem,
update database.)
Parallelizing software updates or installations would be *begging* for
pain. It would be difficult for me to recommend strongly enough
against this.
Please be specific about the pain points that you fear.
The three-stage "manual" pipeline achieves 2x to 3x faster throughput
with error states that are isomorphic to present RPM. (Consider the
Turning machine model: if you don't write to the filesystem, then
there is no change of external state.)
The "parallelize everything that has no remaining predecessors" strategy
requires parallel transactions in the database (they cannot interfere
because that would be a predecessor constraint) and checking for
resource exhaustion (file space, inodes, etc.) as a global
predecessor constraint. What else?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
