>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes:
dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
dv> [...] You'd understood that it doesn't fit mine.
>>
>> Ah! No, I hadn't. Please explain why.
dv> Because, as I've already explained, I already have network-ally shared
dv> standard directories, that your design won't use and it's a shame because I
dv> would have to make the concerned packages directories sharable by hand (or
dv> script) each time a new package appears.
That's not the case. You need (well, "may want" is probably a better
term) to do this only when a package appears which has both an
architecture-dependent portion and a sizeable architecture-independent
portion. I believe the number of these so far is <5, a small
percentage of the existing packages anyway. *You* don't necessarily
need to do anything in that case, the package installer can take care
of that transparently. Moreover, if we organize the packages right
(namely by making packages fit tightly around their
architecture-dependent portion, which makes sense in other ways as
well), you kan keep the number of these packages close to zero.
dv> Please explain precisely why and how.
In a Unix software installation, you have several keys upon which to
index them, among them:
- architecture
- package
- package component (documentation, binaries, etc.)
- version
- availability
...
Given a hierarchical file system, you need to assign these to depths
in your installation hierarchy. This means that there's an ordering
of these criteria. However, this ordering is not a natural property
of these keys---you'd rather want a database where each of these have
equal precedence. The GNU standards impose one such ordering by
having (I may be wrong since we don't use it) a share/ hierarchy and a
lib/ or libexec/ hierarchy, deep underneath which lie the
architecture-dependent portions.
At least emacs-20.3 has, by default, the following
architecture-specific portions in its hierarchy:
bin/
libexec/emacs/20.3/<architecture>
This means that the architecture-specific parts of Emacs are spread
over two different hierarchies. It would make plenty of sense,
however, to mount the architecture-specific portions of a software
package only on the machines of that particular architecture. (In
fact, at least he popular AMD automounter has native support for that
kind of thing.) The GNU standards make that next to impossible,
requiring at least one additional mountpoint per package.
We happen to have an installation where architecture is the primary
key (i.e. it's at depth 0 in the hierarchy). Needless to say,
packages using the GNU standard do not cooperate too well with it.
>> Once the package is spread out as you suggest, installation is still
>> easy enough, but suddenly, if I want to uninstall or move or ship a
>> package, I have to remember where all its bits are.
dv> You told me to use scripts to make my links, so I tell you to use
dv> scripts to uninstall. Moreover, remembering to look in *two* places, like
dv> share/ and lib/, is not that much to remember I think.
There are more than two places: You get one additional place per
architecture, if you do this right.
>> Seriously, links *are* Unix's native mechanism for expressing sharing.
>> You may not like it, but it's the only thing there is.
dv> There are NFS, automount ...
NFS is far from a "native mechanism" for Unix. It doesn't implement
Unix filesystem semantics (or any semantics, for that matter),
and automounting is far from standardized. It doesn't run on my Unix
box, for instance.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
