On 2022-01-16 Thomas Dickey <[email protected]> wrote: > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: [...] > > I would like to question the introduction of another binary package: > > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > > "byacc2" only finds links related to this RFS.
> Ultimately that's because Debian's the only place where the older "btyacc" > is packaged. [...] > > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance > > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward > > compatible extension of /usr/bin/byacc the only difference being > > that it additionally supports > > | -B create a backtracking parser > I've made some effort to keep > the two compatible, but sooner or later will get some bug report related > to their differences. Debian's the usual place for that sort of thing. [...] > ...with these caveats: > a) because of the backtracking support, the skeletons differ. > b) backtracking can be slow > However, Mageia and OpenSUSE provide packages for byacc with backtracking > enabled. [...] Hello Thomas, afaict from https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec Fedora also builds without backtracking: | # Revert default stack size back to 10000 | # https://bugzilla.redhat.com/show_bug.cgi?id=743343 | find . -type f -name \*.c -print0 | | xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 10000/g' | | %build | %configure --disable-dependency-tracking | %make_build I would think that is something you need to solve upstream. It cannot be a good thing(TM) if the same version of byacc is incompatible between different major distributions. Don't you agree? With "solve" meaning, that you decide whether you intend to provide a limited-feature-set binary forever, and starting from there decide on the naming of old (if it shall exist) and new byacc. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
