Re: /usr/dict/ -> /usr/share/dict/ request (bug #110632)
On 1 Sep 2001, Richard Kettlewell wrote:
> Ethan Benson <email@example.com> writes:
> > Richard Kettlewell wrote:
> >> Ethan Benson <firstname.lastname@example.org> writes:
> >>> Richard Kettlewell wrote:
> >>>> Mikael Hedin <email@example.com> writes:
> >>>>> The directory /usr/dict cannot exist on a FHS compliant system,
> >>>> Chapter and verse? I see nothing prohibiting a few symlinks in the
> >>>> aid of backwards compatibility.
> >>> that turns into a discusting mess very quickly. just look at a
> >>> solaris system sometime.
> >> That's your personal opinion of symlinks, not a reference to the
> >> FHS.
> > the FHS says /usr/share/dict not /usr/dict. end of story.
> I still see nothing prohibiting a few symlinks in the aid of backwards
> compatibility. You are continuing to post your personal opinion,
> rather than anything based on the text of the standard.
FHS 2.1, section 4: The /usr Hierarchy
No large software packages should use a direct subdirectory under the /usr
hierarchy. An exception is made for the X Window System because of
considerable precedent and widely-accepted practice. This section of the
standard specifies the location for most such packages.
"/usr" "Secondary Hierarchy"
X11R6 X Window System, version 11 release 6
bin Most user commands
games Games and educational binaries
include Header files included by C programs
local Local hierarchy (empty after main installation)
sbin Non-vital system binaries
share Architecture-independent data
src Source code
I think it's reasonable to interpret "no large software packages should use a
direct subdirectory under the /usr hierarchy" as also applying to /small/
software packages, such as dictionaries. The above are the subdirectories
mandated by the FHS. Also allowed are:
/usr/spool -> /var/spool
/usr/tmp -> /var/tmp
/usr/spool/locks -> /var/lock
for backwards compatibility only. It's implicit in the language that
anything else is prohibited by the FHS.
Of course, since /usr/doc is not listed even among the backwards compatibility
directories, Debian is not strictly compliant with this understanding of the
FHS. But that doesn't mean we should make things worse by providing
additional symlinks for software that should be updated to use the new
directory structure. Let the site admin take responsibility for such
software, not us.