[5154] in SIPB bug reports
Re: reorg of the SIPB locker
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Feb 13 10:02:56 1995
To: John Hawkinson <jhawk@MIT.EDU>
Cc: Marc Horowitz <marc@MIT.EDU>, yandros@MIT.EDU, bug-sipb@MIT.EDU
In-Reply-To: Your message of "Mon, 13 Feb 1995 09:31:55 EST."
<9502131431.AA27788@portnoy.MIT.EDU>
Date: Mon, 13 Feb 1995 10:01:25 EST
From: Greg Hudson <ghudson@MIT.EDU>
> I agree w/ Marc, who said:
[...]
> But for a different reason. All of the others require using "share"
> for scripts -- I think this is confusing when compared to the 44lite
> definition of /usr/share, which is: ``architecture-independent ascii
> text files''. Maybe it's obvious to everyone else that scripts are
> indeed ``ascii text files'', but this isn't clear to me :-) Further,
> BSD share hierarchies are typically structured rather than flat, as
> I would expect /mit/sipb/[WHATEVER]share to be.
1. NetBSD defines share as "arhitecture-independent data files" and
has files such as /usr/share/misc/termcap.db, which are not ASCII text
files. So even if you had non-ASCII executables that worked on all
platforms, I don't think this would be a violation of established
practice. (If BSD 4.4lite really used the wording "acsii text files,"
it was probably based on the assumption that only ascii text files
could be architecture-independent.)
2. I don't think /usr/share is particularly structured under, say,
NetBSD. You have application-specific directories
/usr/share/{calendar,gnats,groff_font,mk,ms,nls,tmac} and then things
like /usr/share/{dict,zoneinfo,skel} which aren't application-specific
but aren't wide categories either. Marc was arguing that /usr/share
should contain wide-category directories like "man" and "lib", but
that's just not how it's used.
3. The reason I don't like Marc's scheme is that he doesn't have clear
definitions of most of his directories, and his vague definitions are
all based on loose ideas about prior practice. For instance, he would
have:
/mit/sipb Software maintained by SIPB
/mit/sipb/arch Architecture-dependent files
/mit/sipb/arch/pmax_ul4/bin Decstation binaries
/mit/sipb/arch/common Files that would be architecture-
dependent, but aren't
for some reason
/mit/sipb/arch/common/bin Architecture-independent
executables
/mit/sipb/arch/common/lib/appl Files for application "appl"
(which would never be
architecture-dependent, but
people are "used to" finding
them in lib).
In constrast, I have:
/mit/sipb Software maintained by SIPB
/mit/sipb/arch Architecture-dependent files
/mit/sipb/arch/pmax_ul4/bin Decstation binaries
/mit/sipb/arch/pmax_ul4/lib Decstation libraries and
Decstation-specific data files
/mit/sipb/arch/pmax_ul4/libexec Decstation auxiliary executables
/mit/sipb/share Architecture-independent data
files
/mit/sipb/share/appl Data files for application "appl"
/mit/sipb/share/exec Architecture-independent
executables
There aren't any "buts" or any appeals to common practice, and this is
how things are structured on a NetBSD system (with the exception of
/mit/sipb/share/exec, which has never been an issue for operating
systems, and /mit/sipb/arch/pmax_ul4/lib's inclusion of
architecture-specific data files; NetBSD has successfully avoided the
use of such things).
Finally, let me make note of the fundamental problem behind
architecture-independent executables and fonts: the problem is a
conflict between placement (which would put the files in an
architecture-inspecific directory) and reference (users should refer
to the files in an architecture-specific directory because the files
could be architecture-specific in the future). I think symlinks from
the architecture-specific directory to an architecture-inspecific
directory is a perfectly good way of solving this problem. Marc
thinks the creation of an "architecture-inspecific
architecture-specific" directory is a more "parallel" way of solving
this problem; I guess I just don't see his reasoning.
