Re: Loop in vi

[Gordon Matzigkeit <gord@trick.fig.org>]

>>>>> Dale Scheetz writes:

 DS> I still see an implication that the two are distinct and
 DS> separate, although it is, indeed, vague.

It is vague by design.  Thomas Bushnell, chief architect of the Hurd,
was partly involved in the creation of the FSSTND.  He tried hard to
make sure that having / and /usr be the same directory wasn't a
violation of the standard.

 >>  Also note that the hurd allows for the boot process to have some
 >> of the binaries in one physical region and the bulk of the
 >> binaries in another physical region even though they show up in
 >> the same directory.

 DS> That's a neat trick. How does it deal with binaries on two
 DS> separate phisical regions that have the same name, when both
 DS> regions are mapped to the same directory?

As others said, this feature is not yet implemented, but the basic
idea is that the user would have different ways (config file, command
line options, etc) of specifying the relative priorities of files that
come from different places.  In this case, we'd just tell shadowfs
that /usr was higher priority than /.

 DS> There is still a problem if you re-install/upgrade ae, as it will
 DS> put the script back in place on the upgrade, but then vi will do
 DS> the same, so it will depend on the order of upgrade as to which
 DS> gets control.

Aha.  That's one more reason to make ae work its /bin/vi magic in its
postinst rather than the package itself.  Feel free to ask me if you
want help with the shell scripting for this.

 DS> Doesn't dpkg complain when it tries to "overwrite" a file from
 DS> one package with the same file from another?

Not by default anymore.  Somebody turned that feature off (I think
because of the problems that come up when packages are reorganized).

 DS> I suspect that vi is only a tiny part of the problem of linking
 DS> /usr to /.  This not only makes /usr/bin isomorphic to /bin, but
 DS> /usr/lib and /lib, and /usr/sbin and /sbin also get overlapped. I
 DS> can't believe that ae represents the only file overlap in that
 DS> whole collection.

So far, it's the only overlap in the whole collection that I've
noticed.  We'll deal with the others as we notice them.

Thanks,

-- 
 Gordon Matzigkeit <gord@fig.org>  //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)