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

Re: Loop in vi



On Thu, 15 Apr 1999, Raul Miller wrote:

> Dale Scheetz <dwarf@polaris.net> wrote:
> > Linking /usr to / is a broken idea. The FHS/FSSTD makes it clear that /bin
> > and /usr/bin are to be different locations and contain different binaries.
> 
> Eh?
> 
>    o The primary binary directories, /bin and /usr/bin, do not have well
>      defined divisions between them.  As a result, the distribution of
>      the binaries between these two directories varies greatly between
>      the Linux distributions.

Sorry, I sometimes mistake Debian's implimentation with the standard. I
still see an implication that the two are distinct and separate, although
it is, indeed, vague.

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

> > In addition, /bin/vi is a script, installed in the root.bin of the rescue
> > floppy so that the vi command will provide an editor during base
> > installation. As soon as one of the "real" vi's gets installed (on a
> > system with /usr linked to /) the script will be overwritten by the new
> > symlink for update-alternatives that the various vi use.
> > 
> > OK?
> 
> That said, I don't see why (given the capability of the hurd to overlay
> physical storage) the hurd can't have what debian linux labels /bin/vi
> present at boot time but what debian linux labels /usr/bin/vi present
> once the system is all the way up.  If it can't manage this then yeah,
> it's probably a mistake to merge /bin/ and /usr/bin/.

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

Doesn't dpkg complain when it tries to "overwrite" a file from one package
with the same file from another? Does it recognize the physical reality,
or only look at file lists provided in the "database" to determine if
there is a file conflict?

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

Thanks,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-


Reply to: