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. Vincent
Attachment:
signature.asc
Description: PGP signature