The problem is that if an author of a module (or script) needs to use
Unicode::Collate then they need to make sure that there is an
allkeys.txt file installed.
Since you can not directly write a dependency on a .txt file that CPAN
will pick up and offer to install I proposed U::C::allkeys.pm as a
simple module that provides the allkeys.txt file and dummy module to
satisfy the dependency check.
However, if module authors start writing that as a dependency then
anyone who is already using Unicode::Collate and has tailored
allkeys.txt will have that file blown away when U::C::allkeys is
installed.
Also if they tailor the file put into place by U::C::allkeys, if an
upgrade of that module occurs then they will lose their tailoring.
I thought separating the unicode provided file from the custom one
might be a preferred way to do it.
If you don't think anyone will edit allkeys.txt directly, but will
always use the table argument to name the alternate then I agree that
there is no problem.
I hope that clarified things...
-ben
On Thu, May 15, 2003 at 10:29:41PM +0900, SADAHIRO Tomoyuki wrote:
A user of Unicode::Collate::allkeys wants to
upgrade allkeys.txt, isn't he/she?
If it would be so, Unicode::Collate::allkeys
can overwrite an old allkeys.txt.
If someone wants to keep his/her allkeys.txt as it is,
he/she can determine to avoid Unicode::Collate::allkeys.
IMO, a bad thing is that upgrade of Unicode::Collate
would force upgrade of allkeys.txt silently.
If allkeys.txt is provided as Unicode::Collate::allkeys,
I don't think Unicode::Collate should need any change at present.
If Unicode::Collate still has some problem, please tell me it.
Thank you.
SADAHIRO Tomoyuki
