Sorry for the delay re-packaging Sunterlib. Please bear with me, I
think my brain is still stuck in the "design" phase. I'm looking at
the design paper at:
http://lamp.epfl.ch/~schinz/scsh_packages/proposal.txt
Michel's proposal tackles many issues:
1. package identification and naming
2. package use
3. package directory layout
4. package distribution (archive contents)
5. package (un)installation
I can't talk about all this in one design pass. I don't know if it is
even necessary to set policy about all of these points. I think that
points 1, 2, and shallow part of 3 are generic issues with the highest
priority for standardization. Whereas 4, 5, and deep part of 3 could
vary somewhat among packages, or even package versions without any
harm. In this message, I will just talk about package directory
layout.
First let me draw your attention to the Filesystem Hierarchy Standard
(FHS):
http://www.pathname.com/fhs/2.2/fhs-4.11.html
I think it is possible to reach common ground between the FHS
principals and Michel's design goals:
usr/
|-- lib
| |-- s48
| | `-- modules
| `-- scsh
| `-- modules
| `-- foo-1.0
| `-- foo.so
`-- share
|-- doc
| |-- s48
| | `-- modules
| `-- scsh
| `-- modules
| |-- foo-1.0
| | `-- COPYING
| `-- foo-1.1
| |-- COPYING
| |-- README
| `-- html
| `-- index.html
|-- s48
| `-- modules
`-- scsh
`-- modules
|-- foo -> foo-1.0
|-- foo-1.0
| |-- foo.scm
| `-- load.scm
`-- foo-1.1
|-- icons
| |-- close.png
| `-- open.png
|-- load.scm
`-- scheme
`-- foo.scm
NOTES:
1. NEGATIVE -- everything is not in one hierarchy. I think this was an
original design goal, and it is lost. This breaks Michel's idea for
uninstallation (delete a single subtree). If this goal can't be
sacrificed, then one way to achive it would be to severely restrict
the proposal to deal with scheme source code only. My personal view is
that this design goal is not practical in the Unix context.
2. POSITIVE -- multiple architectures. The problem with machine
dependent files (shared libraries, etc.) is solved. They go in the
.../lib directories which are not shared among different
achitectures. The machine independent files (including scheme sources)
go in the .../share directories; they are shared among machines with
different architectures.
3. POSITIVE -- miscellaneous docs are found in the place that users
will look for them (../share/doc/...). It is incorrect to store this
information in .../lib.
4. NEUTRAL-POSITIVE -- Note that still only one symbolic link (foo ->
foo-1.0) is necessary for the "active" version feature. This design
does not required programmers to add any extra directory levels when
using the active version of the script (to load active use:
foo/load.scm to load versioned use: foo-1.1/load.scm).
5. BIG-POSITIVE -- Our packages will conform to the FHS. My operating
system's policy (Debian's) requires this for all packages, I'm sure
that others do too.
--
Anthony Carrico
|