On Tue, Apr 12, 2011 at 7:00 PM, Sebastian Nowicki <[email protected]> wrote:
> On Tue, Apr 12, 2011 at 2:46 AM, Dan McGee <[email protected]> wrote: > >> On Sun, Apr 10, 2011 at 5:58 AM, Sebastian Nowicki <[email protected]> >> wrote: >> > In addition to the names of the conflicting packages, the origin and >> > versions will be displayed to the user. >> > >> > This introduces an API change in the PM_TRANS_CONV_CONFLICT_PKG >> > conversation callback. All three arguments were strings. The first >> > two arguments are now pmpkg_t structures (sync and local, respectively). >> > >> > Fixes FS#12536 >> > --- >> > >> > In FS#12536 there was some discussion about changing pmconflict_t to >> > contain pmpkg_t structures rather than just strings. This would >> > be a much larger change, which I didn't think was worthwhile for >> > a cosmetic change. >> > >> > Even so, this does introduce an API change, and a sneaky one at that. >> > The conversation callback had three string arguments, now it has two >> > pmpkg_t and a string. Due to these being all void pointers, end-users >> > won't get any compiler warnings/errors if they don't update their code! >> >> Any consideration to just building the relevant string in the backend >> so we don't need 1) an API change and 2) the awfully ugly code in the >> frontend to print what you are printing? >> > > This would work for pacman, but I don't think it's ideal for other > front-ends (especially GUI). As a front-end developer, I'd prefer having the > data in the callback rather than pre-processed information. > On second thought, this would be a good compromise. If front-ends require the pmpkg_t structure, it can be added later on. There's little harm in changing the strings, although, in a way, this would still be an API change (if the front-end relies on the string being the name for some reason).
