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 <[email protected]> wrote: >>> >>> On 9/3/20 6:55 am, Anatol Pomozov wrote: >>>> On Sun, Mar 8, 2020 at 6:05 AM Allan McRae <[email protected]> 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 ...
