Hi, After me: > > 1) Have a bison-runtime package that contains the .mo files, unversioned. > > 3) Have a package-dependent bison-runtime package, shipped with and > > installed by each package that uses a parser. > > ... > > The patch I submitted uses approach 3. But I admit that approach 1 is > > also tempting.
Paul Eggert wrote: > I see the temptation, but I'm inclined to think that (3) is the better > choice, at least at first. The more I think about it, the more I prefer solution 1. It has the advantage of being simple. So the two drawbacks that we know (bison-runtime.pot can only grow, and the distributors must learn to split a package into a -runtime and a -dev package [which they haven't learned so far for gettext...] and set package dependencies) are the only ones that we'll have to face. Whereas solution 3 is so complex that more things can go wrong, which are hard to diagnose: - If the package maintainer forgets to distribute the bison-po directory... - If the package maintainer forgets to invoke BISON_I18N... - If the package maintainer forgets the second bindtextdomain() invocation... And it doesn't make itself ridiculous by copying the same files onto the user's disk. > (An advantage to (3) is that the work is already done. :-) That doesn't matter. I will redo the patch for (1). Bruno
