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

Re: /usr/share?

On Mon, Jun 01, 1998 at 05:02:10PM -0500, Manoj Srivastava wrote:

>  Marcelo> Ian (I think) said one of the goals for slink would be not
>  Marcelo> to repeat what happened with hamm, that is, packages from
>  Marcelo> hamm can't be installed on bo without heavy upgrading, if at
>  Marcelo> all.
> 	Is that not because f glibc2 issues? Putting package internal
>  files in /usr/share does not in any way make hamm and slink
>  incompatible. 

What I mean here is that moving things from one directory (/usr/lib,
/usr/X11R6/lib, /usr/whatever) to another (/usr/share) calls for lots of
symlinks for backwards compatibility, in order to avoid breaking installed
packages. You have a point, this is not as bad as the glib2 thing. Somebody
already pointed out the /var/mail issue (which I *do* think belongs in
/var/spool/mail) which will break mail readers, but heck, one can always
make a symlink (at it looks like most of us like /var/spool/mail better)

>  Marcelo> Cluttering /usr/share/ with loads of $package directories is
>  Marcelo> not a really good idea.
> 	Reasons, please. especially reasons with the long term use of
>  /usr/share in mind. 

Ok, I overstated the situation. It's not incompatibility. It's more like
chaos. This is from a little hamm box:

[1 mmagallo pollux:~] ls /usr/share/
a2ps          consolefonts  games         keytables     terminfo
aclocal       consoletrans  gimp          locale        xemacs
awk           doc-base      groff         misc          xemacs20
base-files    emacs         i18n          site-lisp     zoneinfo
base-passwd   emacs20       icons         tabset

most of the directories here are for a single package. FSSTND doesn't
mention /share/locale, FHS does. But neither mention i18n (that comes from
the locales package, may be package specific, in which case it would be nice
to name it after something less generic). Nor icons. FSSNTD doesn't say
anything about /usr/share/games. FHS does. (Question: what the heck was
followed in hamm then?!? FHS? FSSNTD? A mixture?) In fact, hamm includes all
of this under /usr/share:

XaoS a2ps aclocal afterstep apache applnk apps automake awk base-files
base-passwd comerr consolefonts consoletrans cutils dfm dict
display-dhammapada doc-base emacs emacs19 emacs20 explorer games gcal gforth
gimp gnuplot groff guavac guile i18n icons jered keytables le libtool
lilypond locale mimelnk misc mysql octave ppd rfc site-lisp skk ss state
tabset terminfo tkgnats tm toolbar troffcvt typist wallpaper xemacs xemacs19
xemacs20 xlp zile zoneinfo

and all of this under /usr/lib

Acrobat3 CTI-Print GNUstep R THE abc2ps acs addressbook af afbackup alien
amanda analog apache atalk autoconf autofs awe awk ax25 axene bcc bigloo
biss-awt bitchx calc calendar cern-httpd cfengine cflow cgi-bin cthugha cvs
cweb deb-make debhelper debiandoc-sgml debug dejagnu devscripts dict dist
distributed-net-pproxy dosemu dpkg dqs dsssl dunc dupload dwww elk elvis
emacs emacsen-common enscript entity-map epan epic exim exmh felt festival
fidogate figlet file-rc flin fonts frad ftnchek games gap gcc-lib gcl gfont
gforth ghostscript gimp git glib gnats gnuplot gopher htdig hwtools
hyperlatex ical icon icons ifmail ilu im inform irc ircd isdn ispell jade
javalex jed jove kernel-package latex2html lclint ldscripts lg libc5-compat
libfakeroot lisp loadlin locate lout mailagent majordomo mc megahal menu
mercury mh mhonarc mime mirror mk mkrboot mmm mon mpage mpich mush mysql
netboot netdiag netscape news nn noweb ocaml octave p2c p3nfs pccts pdmenu
perl5 pgplot php3 picon pike pinepgp pix plan postgresql povray3
procmail-lib profile pstoedit psutils pvm3 python qweb router roxen rscheme
sam saoimage saytime sc scilab scm scsi sdc security sgb sgml sgml-data
sgml-tools siag sirc skk slib slice slsc smail smalleiffel smtp-refuser snns
sp sp-dev spamdb spamfilter spim squid strn swi-prolog syslinux tclX tclmidi
tcpquota texmf thot timidity tkX tkcvs tkdesk tkgofer tkmail tkps tkrat
tkstep tripwire trn ts ucblogo ucbmpeg uucp vice vim visual-tcl wine wml
wmmail wn wnn wpe wwwcount x10-automate x286emul xadmin xaw-wrappers
xcircuit xemacs xfmail xisp xlispstat xmysql xmysqladmin xtrkcad xtrs xzx
yorick yp zed zmailer zsh


FHS says /usr/lib/ is for libraries and private binaries and /usr/share is
for static shareable data. So, many (most?) of the things in hamm installed
on /usr/lib should be moved to /usr/share. More specifically, FHS 2.0 says:

  /usr/lib includes object files, libraries, and internal binaries that are
  not intended to be executed directly by users or shell scripts.

  Applications may use a single subdirectory under /usr/lib. If an
  application uses a subdirectory, all architecture-dependent data
  exclusively used by the application should be placed within that
  subdirectory. For example, the perl5 subdirectory for Perl 5 modules and

  Miscellaneous architecture-independent application-specific static files
  and subdirectories should be placed in /usr/share.

regarding /usr/share it says:

  Any program or package which contains or requires data that doesn't need
  to be modified should store that data in /usr/share (or
  /usr/local/share, if installed locally). It is recommended that a
  subdirectory be used in /usr/share for this purpose. 

  It is recommended that application-specific, architecture-independent
  directories be placed here. Such directories include groff, perl,
  ghostscript, texmf, and kbd (Linux) or syscons (BSD). They may, however,
  be placed in /usr/lib for backwards compatibility, at the distributor's
  discretion. Similarly, a /usr/lib/games hierarchy may be used in addition
  to the /usr/share/games hierarchy if the distributor wishes to place some
  game data there.

That part ("distributor's discretion") doesn't play well with the LSB thing,

Am I making a point? I don't think so... afterall, this is not what I was
asking in the first place... or was it? ;-)


To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: