Re: Announcing DNF 3 development

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 22 March 2018 at 17:49, John Reiser <jreiser@xxxxxxxxxxxx> wrote:
> 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?
>

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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx



-- 
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux