[bam@snoopy.apana.org.au: Re: Settle for /usr symlink (!)]
Hello,
Brian asked me to forward this.
Answer in a different mail.
Thanks,
Marcus
----- Forwarded message from Brian May <bam@snoopy.apana.org.au> -----
Delivered-To: Marcus.Brinkmann@ruhr-uni-bochum.de
To: Marcus.Brinkmann@ruhr-uni-bochum.de
Subject: Re: Settle for /usr symlink (!)
Reply-To: bam@snoopy.apana.org.au
Newsgroups: local.lists.debian.hurd
Organization: Snoopy's Organization
Date: Mon, 08 Mar 1999 18:48:01 +1100
From: Brian May <bam@snoopy.apana.org.au>
X-UIDL: 69d8329faa95ed066a8a86b3b3b16a05
In article <[🔎] 19990308013350.G24261@ruhr-uni-bochum.de> you write:
>On Sun, Mar 07, 1999 at 07:21:06PM -0500, Roland McGrath wrote:
>> If you are not using a /usr symlink, and install things in /usr/include,
>> it seems appropriate to have a symlink /include -> usr/include for
>> compatibility with no-/usr systems.
>>
>> This is not to express any opinion about /usr symlink vs not.
>
>I thought of that, but how far does this go? Do we also need a symlink
>/shar -> /usr/share? What about the libraries (is /usr/lib searched by now?)
>
>How many of such situations will arise? I just don't know. I am willing to
>try my best to make both situations possible, but if we choose one
>officially as the default, we can concentrate on that, and fix the other as
>problems arise.
>
>And in this case, the missing symlink /include would result into subtle
>problems.
>
>And, the /usr symlink itself is only ducking. The real challenge is to drop
>it sometime later and change the Debian packaging rules. :) But this will be
>a long way.
Issues to think about for the future:
--------------------------------------
1) Changing /usr to a symlink
Problems:
1.a) each package must be checked to ensure that it is compatable
with the new scheme.
1.b) breaks Debian policy as it doesn't comply with file system
standard.
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)???
--------------------------------------
2) The biggest problems I see with completely removing /usr.
Problems:
a) the enormus number of Debian packages that must be changed.
b) changing *every* reference in each package, including
any references in the documentation to /usr/...
--------------------------------------
3) Consider that every package in a Debian distribution (currently) has
the same source code regardless of the architecture. I think it would
be messy if we (now or in the future) had to allow for a special case
in every source package (not to mention documentation!) for these
differences; maybe this is a limitation in how Debian packages are
currently created (...topic of further discussion... I would suggest
making source packages independant of the final layout of directories)
however this won't get changed overnight.
Problems:
a) the enormus number of Debian packages that must be changed.
3.1) If (1) and (2) go ahead as planned, the documentation will also
have to be independant of the final layout of the directories, too,
yuck. This includes man pages, info pages, etc, I don't know how many
are affected, but I am sure there will be plenty.
Problems:
a) the enormus number of Debian packages that must be changed.
--------------------------------------
4) Also, it was once suggested that files for packages could live in
directories like /package/{telnet,ftp,tetex,etc}/{bin,man,sbin,etc}/,
and merge everything into /bin, /man, /sbin, /etc; I don't know if this
is still practical; I think you would have far to many subdirectories to
merge if there is one for each package.
--------------------------------------
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.
Point to ponder: Should the documentation refer to files under /etc or
/package/section/etc??? I suggest /etc, as this doesn't require
any changes to documentation, avoiding the need for (3.1).
5.1) (5) could be implemented by dpkg setting root-path when
unpacking the files avoiding the need for both (3) and (3.1).
--------------------------------------
6) Final Comments:
(3) would be required for (1).
(3) could also be used by (4) or (5) but that isn't required.
(3.1) would be required for (2).
--------------------------------------
7) My opinion:
I think it is best to avoid (3) and especially (3.1) if at all possible.
Personally, I really dislike (1) and especially (2); if we kept /usr, we
won't have to do (3.1).
I would prefer to do something like (5) and (5.1) with the /usr directory,
which means that no source packages need to be changed.
Comments anyone?
----- End forwarded message -----
--
`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: