[pacman-dev] [PATCH] Add more information in conflicts question

[Sebastian Nowicki]

On Tue, Apr 12, 2011 at 7:00 PM, Sebastian Nowicki <sebnow at gmail.com> wrote:

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