Re: Settle for /usr symlink (!)
Hello Brian,
I will tell you why I don't think your analyse is correct.
It is not planned to remove the /usr symlink anytime soon, so we should not
worry about it (I should not have mentioned it in my last mail).
However, the Hurd system _is_ different from Linux. We must accept that. The
Hurd system offers also advanced capabilities like translators, and there is
no technical reason for using /usr (first, it had to to with tapes, now it
has to do with partitions. The Hurd will have shadowfs, which will make it
possible to mount several partitions at the sameplace, overlaying each other
transparently).
So, I am indeed willing to ignore Debian Policy in certain points, because
it was never revisited for Linuxisms. In the end, I expect some additions or
exceptions to Debian Policy for the Hurd. To work out how much is needed and
how much is feasible is one task of our project.
On Mon, Mar 08, 1999 at 06:48:01PM +1100, Brian May wrote:
> --------------------------------------
> 1) Changing /usr to a symlink
>
> Problems:
> 1.a) each package must be checked to ensure that it is compatable
> with the new scheme.
Yes, this will be done over time. Currently only cpio and ae breaks a bit.
> 1.b) breaks Debian policy as it doesn't comply with file system
> standard.
See above. You are correct, but the Debian policy is currently a Debian
GNU/Linux policy, and some aspects need to be revisited.
> Is it really worth the effort just to get rid of /usr (not to mention
> breaking the filesystem standard, hence Debian policy in the process)???
It is far severe. We must do it. Although there are ways around, not using a
symlink but a seperate directory tree will be much harder to maintain in the
future. This is because /usr-> is just one symlink back. If it were a
directory, we would probably need multiple symlinks, for example for
/include -> /usr/include, /usr/lib -> /lib (I am not sure about this with
recent glibc).
Considering the design of the Hurd, and the nature of the /usr symlink, I
don't expect too much trouble with it. Remember that /bin and /usr/bin as
well as /sbin and /usr/sbin are not problematic (overlaps are not a good
idea anyway, exception is cpio). Furthermore, /lib should not be a big
problem, too (only thing I know is libc5-compat, which does not apply to
hurd). All other directories are not problematic, IIRC.
I thought we could probably support both. But now that I see that /usr as a
real directory needs some cludges I consider to be dirtier than the /usr
symlink (which is easy and clean, if the two packages are fixed), I am much
in favour of the symlink.
Brian, I don't know if you have read the prior discussion about this. Please
check the mailing list archive, there was some discussion.
> --------------------------------------
> 2) The biggest problems I see with completely removing /usr.
We should probably not think about this now. This is something we can talk
about in a few years.
> --------------------------------------
> 5) Maybe a better idea would be to have seperate groups of packages,
> eg: /package/{base,network,x11,news,mail,etc}/{bin,man,sbin,etc}/
> (these could correspond to the different sections already in Debian!)
> Hence, it would be easy to put all x11 files on another partition, if
> desired, and if this partition failed, only x11 files would be effected.
shadowfs does this better, really (when it does it).
> (3) would be required for (1).
Not really. Please reconsider the issue, and keep inmind that GNU stuff will
default to /include, /lib and so on in future.
Note that still you could make /usr a real directory, but you must expect
unencountered problem. For example, compiling of egcs will succeed, although
it has wrong limits.h file in future, if include files are not accesible
via /include. I think we should try to support both as long as possible,
but one should be recommended and official.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: