On Tue, Apr 12, 2011 at 7:00 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On Tue, Apr 12, 2011 at 2:46 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Sun, Apr 10, 2011 at 5:58 AM, Sebastian Nowicki <sebnow@gmail.com> 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).