Re: Proposing new virtual packages for engine/gui compatibility
Looks like I missed one step here and omited to followup.
There is an official policy enhancement request at
https://bugs.debian.org/779506, which is looking for seconds. It
would be great if some of you could take the time to review it.
Bet regards,
--
Yann
On Sun, Feb 08, 2015 at 12:58:16PM -0500, Vincent Legout wrote:
> 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
Reply to: