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

Re: Berlin & FSSTND/FHS

Tamas TEVESZ wrote:
> On Sat, 3 Jul 1999, Robert Thomson wrote:
>     /usr/bin/X11 -> /usr/X11R6/bin
>     /usr/lib/X11 -> /usr/X11R6/lib/X11
>     /usr/include/X11 -> /usr/X11R6/include/X11

As X has these folders and people do find them acceptable, would it be equally
exceptable to do the same for Berlin? For example:

	/usr/bin/Berlin/ 	-	Berlin Applications
	/usr/lib/Berlin/	-	Berlin Libraries
	/usr/include/Berlin/	- 	Berlin Headers
	/usr/share/Berlin	-	Berlin Static Data

While the old Unix semantics for filesystem hierarchy are very useful for small
console applications which do not typically contain much more than system
utilities, I feel them strongly lacking for larger, more complex applications.

Managing namespace is always difficult. The partitioning of namespace is already
accepted throughout Debian. /usr/doc contains directories for specific package
documents instead of throwing all documents in one place, /usr/lib contains
several directories containing libraries for specific packages not meant to be
linked by other applications, /usr/share is nothing but directories devoted to
various applications.

So the question is, if you are going to partition namespace, where do you want
to do it and why do you want to do it?

I can see 3 types of partitioned namespace in Unix; software package,
environment, and file/data type.

Now is creating the partition in /usr any less evil than creating it in
/usr/bin, /usr/lib, /var, /etc, /usr/share, /usr/doc, etc?

Is it better to scatter a software application distribution throughout a
hierarchy instead of putting it into a single directory in /opt?

And finally, has anyone given any serious thought to just dropping the Unix
filesystem hierarchy standard and starting over?

The reason I ask is because Berlin will have a whole lot of files and I mean, a
whole lot. I'm not sure people really want us polluting the global namespace
with them.


Jordan Mendelson     : http://jordy.wserv.com
Web Services, Inc.   : http://www.wserv.com

Reply to: