wordlist packages: transition to update-alternatives and FHS
Hi,
I've been looking into the possibility of changing the wordlist
packages to use update-alternatives instead of their own
slightly-broken variant thereof. I considered the transition to
FHS-compliant locations, too. Here are my thoughts so far.
The current layout is like this:
/usr/dict/words -> /etc/dictionary
/etc/dictionary -> /usr/dict/<language>
... where the sysadmin picks <language>.
Making both the FHS and update-alternatives transitions would give:
/usr/share/dict/words -> /etc/alternatives/dictionary
/etc/alternatives/dictionary -> /usr/share/dict/<language>
In other words, there are no files in common between the new and old
schemes. We should be able to introduce the new scheme in new
packages, letting the {pre,post}rm maintainer scripts of the old
versions clean up the old files. The old packages wouldn't have to
know about the new layout, and the new ones needn't know about the old
layout.
The maintainer scripts of the new versions could possibly examine the
old state of affairs and "prime" the alternatives system with the same
settings that were made under the old system. (Simply stuffing an
appropriate symlink into /etc/alternatives is enough to make
update-alternatives use that, instead of installing its own symlink,
even before installing a package for the first time.) I'm not sure
whether this is a good idea, though, especially when it involves
mucking around in /etc/alternatives, which ought to be private to
update-alternatives and the sysadmin. Any thoughts?
One possible problem is that there might be packages (or people) out
there using /etc/dictionary. I don't think this should be the case; I
think /etc/dictionary is an implementation detail of the wordlist
packages, and /usr/dict/words is currently the public interface. Also,
programs like look(1) would have to be modified to look in
/usr/share/dict/words as well as (or instead of) /usr/dict/words.
I'll build a version of wenglish that demonstrates this and upload it
(to experimental or to unstable?) I'm open to suggestions for better
ways to handle this, though.
Thanks,
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Reply to: