[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr/dict/ -> /usr/share/dict/ request (bug #110632)



On 1 Sep 2001, Richard Kettlewell wrote:

> Ethan Benson <erbenson@alaska.net> writes:
> > Richard Kettlewell wrote:
> >> Ethan Benson <erbenson@alaska.net> writes:
> >>> Richard Kettlewell wrote:
> >>>> Mikael Hedin <mikael.hedin@irf.se> 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
lib      Libraries
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.

Steve Langasek
postmodern programmer



Reply to: