On 22 March 2018 at 17:49, John Reiser <jreiser(a)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 <jreiser(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.