Re: Proposing new virtual packages for engine/gui compatibility
On Sat, Feb 07, 2015 at 01:37:43PM -0500, Vincent Legout wrote:
> Hi Yann,
>
> Yann Dirson <ydirson@free.fr> writes:
>
> > If there is no objection, I will submit a patch to debian-policy
> > adding the 2 sets (-ui and -engine) of virtual packages to the
> > official list, for the list of protocols listed above.
>
> I don't really have any objection, I like the idea, but I'm not sure
> about adding that many virtual packages. You listed 9 protocols, this
> means 18 new virtual packages while the current list has 90 virtual
> packages.
>
> I don't play any chess variant or go so I'm biased here, but I'd say uci
> is the most well-known and used protocol. Thus I'd be ok to add virtual
> packages for the uci and cecp protocols, but I'm less convinced about
> the 5 protocols for shogi variants.
>
> Thanks,
> Vincent
Well, that's only 4 for Shogi as UCCI is for XiangQi, but I guess that
does not change much your objection :)
We could reason that CSA is apparently not supported by any GUI we
ship, and that currently the only engine using it is gpsshogi, which
has we can talk to through xshogi and usi anyway. Even Bonanza, which
I may package some day (one of the strongest engines, but not DFSG
because of a "non-commercial use" clause), which uses CSA like most
modern engines to be able to participate in the CSA competition, has a
fork adding CECP support. So we may decide not to use it until it
gets really useful.
And we could argue that xshogi-minishogi support is unlikely to be
added be added in new engines, so it may be sufficient for GUIs to
depend on gnuminishogi directly, but the xshogi-minishogi-ui would
still be needed for gnuminishogi to recommends the matching GUIs. But
as that breaks symmetry, it's a matter of deciding if sparing a
virtual package is worth the possible confusion.
We could also decide that those protocols which only have one single
ui/engine today are not worth a new virtual package (after all, for
USI and UCCI, we just have to add pointers to uci2wb in gpsshogi and
eleeyes respectively, whereas adding the virtual package requires a
uci2wb upload as well), and decide to wait until a new compatible
engine or UI comes.
For Go, we currently have 2 GUI supporting GTP2 (quarry and qgo), one
more I will upload anytime soon (omaha), and although we have only
gnugo as engine today, I also have plans (although no itp yet) to
package more of them (pachi and fuego at least), so that one is in the
short list. I had forgotten about the old GMP protocol, which is
apparently the only one that cgoban can use, and gnugo is apparently
the only DFSG engine still supporting it, so we can probably safely
ignore it.
We I could do is submit a patch with the most useful additions (cecp,
uci, xshogi, gtp2), and mention the other ones as possible additions
for consistency/extensibility. Does that sound better ?
Reply to: