On 22 March 2018 at 17:49, John Reiser <jrei...@bitwagon.com> wrote: > On 03/22/2018 01:51 PM, Nico Kadel-Garcia wrote: >> >> On Thu, Mar 22, 2018 at 10:52 AM, John Reiser <jrei...@bitwagon.com> >> 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? >
Having some way for triggers/postun/pre etc scripts to know they actually interfere with a predecessor constraint. This would mean itemizing everything in every script which could be run during these steps and working out blocks/conflicts/etc. [AKA if bash is not there when a parallel scriplet runs... boom.] [Not saying it is impossible.. but it might mean a multipass update where certain things are updated, then the next set and then the third ... ] > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
