[pacman-dev] [PATCH] Introduce alpm_dbs_update() function for parallel db updates

Allan McRae allan at archlinux.org
Fri Mar 13 00:29:00 UTC 2020


On 13/3/20 10:06 am, Allan McRae wrote:
> On 10/3/20 5:35 am, Anatol Pomozov wrote:
>> Hi
>>
>> On Sun, Mar 8, 2020 at 5:15 PM Allan McRae <allan at archlinux.org> wrote:
>>>
>>> On 9/3/20 6:55 am, Anatol Pomozov wrote:
>>>> On Sun, Mar 8, 2020 at 6:05 AM Allan McRae <allan at archlinux.org> wrote:
>>>
>>>>> I got to here.  Seems a lot of this is duplicated from the single db
>>>>> path.  If both are going to coexist, can we do some refactoring?
>>>>
>>>> It depends whether we want to keep the API backward-compatible. If it
>>>> is fine to break one in pacman 6 release then we can just remove the
>>>> function from ALPM API. Otherwise alpm_db_update() need to be
>>>> reimplemented using alpm_dbs_update() functionality.
>>>>
>>>
>>> I was thinking that a non-pacman frontend may want to update a single
>>> db.  But I suppose they just pass a single db to alpm_dbs_update().
>>
>> Yep. Passing a single element list to alpm_dbs_update() is exact equivalent of
>> alpm_db_update() functionality.
>>
>>>
>>> So, I'm OK with the temporary code duplication followed by change of API
>>> for 6.0.
>>
>> Ok. I will remove alpm_db_update() at the end of this patch series.
>>
> 
> Well...  thinking about this some more, at the end of the patch the
> current alpm_db_update() and alpm_dbs_update() should be renamed to take
> its place.   All our API for db operations is of the form alpm_db_... so
> we should keep it that way.
> 

Words are hard!

... at the end of the patchset the current alpm_db_update() should be
removed and alpm_dbs_update() should be renamed ...


More information about the pacman-dev mailing list