[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposing new virtual packages for engine/gui compatibility

Yann Dirson <ydirson@free.fr> writes:

> 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 ?

Thanks for the explanations about all the engines. Yes, this seems like
a better idea to me. Let's wait until more engines or ui are in the
archive before adding the other virtual packages.


Attachment: signature.asc
Description: PGP signature

Reply to: