Re: r57544 - in trunk/packages/cdebconf: debian src/modules/frontend/newt
On Sat, Feb 14, 2009 at 01:28:33PM +0100, Jérémy Bobbio wrote:
> On Fri, Feb 13, 2009 at 04:44:53PM +0000, Colin Watson wrote:
> > Export a new cdebconf_newt_get_progress_info function so that
> > cdebconf-newt-terminal can reinitialise progress bars (since there's no
> > progress_info member in struct frontend, and it won't fit in the obvious
> > place without breaking the plugin ABI).
>
> Is changing the plugin ABI a real issue so early in the new release
> cycle?
I don't like doing it, especially as we don't have a mechanism to notify
about breakage at the packaging level (SONAME or Provides:
cdebconf-plugin-abi-1 or whatever).
> As far as I know, you are the only maintainer of an out-of-tree plugin,
As far as I know too, but we have no way to know for sure ...
> and if doing an ABI change makes the code cleaner, I think we should do
> it. I might have overlooked something, though…
If the new code had been really horrible, then of course I'd be
considering doing an ABI change. In this case I think the ugliness is
pretty minor, though, and is justified by avoiding even a relatively
small amount of hassle.
In any case, I actually think the *current* interface is kind of ugly.
Poking around inside struct frontend with things like
obj->methods.can_go_back() ... well, let's say it's not my favourite
style of interface and ultimately I'd rather that we used accessor
functions anyway. As such, I don't feel too bad about using an accessor
function here.
I haven't yet thought of any case where anything other than newt would
need this. If we do think of one, then we can always just say that we
postponed an ABI change until that point, and do it then; nothing lost.
Thanks,
--
Colin Watson [cjwatson@debian.org]
Reply to: