On Sat, Dec 30, 2006 at 09:22:40PM +0100, Rene Engelhard wrote: > Agustin Martin wrote: > > What the Ice/Moz people intend for the future? If every myspell app is > > moving to hunspell, I would avoid the intermediate /usr/share/myspell step > > and move every myspell dict to /usr/share/hunspell once this happens, unless > > there is already a real hunspell dict available, where myspell dict package > > should just be removed. In the meantime conflicts and symlinks are OK. > > Apparently there's a patch in Moz's bugzilla for Myspell support. > and there's patches for Iceape and Iceweasel already in the BTS > (the Ice* people are going to apply them once Hunspell has a shared lib) > > When anything using MySpell migrated to Hunspell we can get without > /usr/share/myspell, yes.
I have noticed that hunspell with the shared lib stuff has been uploaded to experimental. So, I suppose that in a reasonable timeframe after etch is released there will be no need for standalone myspell. > > > > Question: Should Hunspell dicts and MySpell dicts for the same language > > > still conflict? Or should there only be a symlink from the hunspell to > > > the myspell directory if there only is myspell dictionary available? > > > > This depends. If myspell and hunspell dicts are to coexist in different > > places because there are apps that require one of them, and that is not to > > vanish in a reasonably near future, we can either make them conflict > > ... which is what we currently do ... > > > or plan a symlink based stuff at e.g. /var/lib/hunspell pointing to > > /usr/share/hunspell dicts or, if unavailable for that language, to > > the equivalent /usr/share/myspell dict. hunspell should look for dicts > > there. > > Hmm, yes, that could be solution. I have been playing with update-openoffice-dicts to be able to read infos from two places with a defined priority. This was more in the '/var/lib/hunspell' way supposing myspell and hunspell dicts are installed in different places, but having the capability does not harm, even if it is finally disabled. I will probably open a dictionaries-common branch to start testing changes before etch is released. Forgot to mention that I proposed /var because /usr might be mounted read-only at dpkg-reconfigure time. However, since everything seems to be really moving to hunspell control, I think we should wait and use /usr/share/hunspell as destination for both myspell anf hunspell dicts, with appropriate conflicts. myspell dicts having matching hunspell dict will eventually disappear. There was other possibility I was considering (unfortunately, I am not the one to code it). Have you seen, when browsing other distros, any code to make hunspell support multiple search paths in a defined priority? That would help us a lot to make the transition smooth (with a search path like /usr/share/hunspell:/usr/share/myspell/dicts), and might be useful even later (think of something like /usr/share/hunspell:/usr/local/share/hunspell). In parallel, I considered filing a feature request on hunspell-sf about this, but did not do before knowing other opinions. > > I would not go that deep for the infos. Since they are Debian only, > > something like /usr/share/ooo/infos should suffice. I am not proposing > > Good idea. That would also make it vanish from the "real" dir. > (I'd use /usr/share/openoffice (sic!), though, probably) That is OK for me, but I would still leave the infos subdir (thus using /usr/share/openoffice/infos), just in case we need to hang something else from /usr/share/openoffice. Happy New year to all, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
