Free Standards Group

> -----Original Message-----
> From: Thomas Sippel - Dau [mailto:t.sippel-dau@...]
> 
> I think Nils's question is worth an answer. Should we:
It would be nice if you somehow quoted the question, I've removed the
origional from my mailbox.
> 
>    o  tell people to put "desktop related stuff" like kde, gnome
>       etc. into /usr/X11, and migrate the name to /usr/X<suffix>

NO! Don't polute other directories! Both gnome and kde should have their own
locations. THey are big enough on their own to have one. According to FHS,
that sould be /opt/gnome or /opt/kde (or should I say /opt/gnome1 ,
/opt/gnome2, /opt/kde2, /opt/kde3 :-)

>       similar to /usr/lib<suffix>, or even to some other name
>       like /usr/dt. 
> 
>       The advantage is that there is a single PATH entry that selects 
>       (or deselects) a large number of commands that are only appropriate 
>       for graphical desktops, and could even be used to judicially 
>       shadow out commands appropriate for serial consoles with the
>       same parameter syntax 

You mention the path: an other reason to have kde, cde and gnome in their
own location: An example of a system that comes with CDE and KDE2 (hence in
/usr/dt and /usr/kde) on which both gnome and KDE3 are added (as with
current fhs: in /opt/gnome and /opt/kde3.) The $PATHs can look as follows:

CDE user:
/usr/bin:/usr/dt/bin:/usr/kde/bin:/opt/kde3/bin:/opt/gnome/bin
KDE2 user:
/usr/bin:/usr/kde/bin:/opt/kde3/bin:/usr/dt/bin:/opt/gnome/bin
Gnome user:
/usr/bin:/opt/gnome/bin:/usr/dt/bin:/usr/kde/bin:/opt/kde3/bin
KDE3 user:
/usr/bin:/opt/kde3/bin:/usr/kde/bin:/usr/dt/bin:/opt/gnome/bin

other directories like /usr/X11/bin, /usr/bin/X11 and variants can be
inserted at any place.

> 
>    o  tell people to stick to /usr/lib/{gnome,kde,...}, 
>       /opt/{gnome,kde,...} and accept that they will do that with
>       link farms like I outlined in an earlier mail.

For link farms: the less links you make, the less you have to maintain.


CBee

> From: Thomas Sippel - Dau [mailto:t.sippel-dau@...]
> 
>    o  tell people to put "desktop related stuff" like kde, gnome
>       etc. into /usr/X11, and migrate the name to /usr/X<suffix>

OK. kde, gnome, etc. is usually X-related stuff, but IMHO prefixing
them with an X doesn't give you much. A user might even get the idea,
that he can link /usr/X to /usr/Xgnome2  ... ;-)
  
>       similar to /usr/lib<suffix>, or even to some other name
>       like /usr/dt. 

gnomeN, etc. below /usr/dt or /opt/dt might be an option (so
e.g. one could export all dektop environments very easy), but 
I guess, than we get trouble with sun or vs. versa ;-)

>    o  tell people to stick to /usr/lib/{gnome,kde,...}, 
>       /opt/{gnome,kde,...} and accept that they will do that with
>       link farms like I outlined in an earlier mail.

I prefer to have the required stuff for a certain DE below one directory
only. Spreading it around makes it more complicated to maintain and
export it to other clients ... Also changing the default DE e.g.
by linking /opt/gnome to /opt/gnome2 would not be easy, at least not,
if the appropriate links are not in /opt/gnome2 are as well. But if
you have the links there, why not directly store that stuff over there?

Regards,
jens.
-- 
+---[ Jens Elkner ]---------[ IMS GmbH, Abt. Server/Netzwerkmanagement ]--+
| Sandtorstr. 23                       +49 391 54486 19230                |
| 39106 Magdeburg                       elkner@...                |
| GERMANY                             http://www.imsgroup.de/             |
+-------------------------------------------------------------------------+

Jens Elkner wrote:
> 
> > From: Thomas Sippel - Dau [mailto:t.sippel-dau@...]
> >
> >    o  tell people to put "desktop related stuff" like kde, gnome
> >       etc. into /usr/X11, and migrate the name to /usr/X<suffix>
> 
> OK. kde, gnome, etc. is usually X-related stuff, but IMHO prefixing
> them with an X doesn't give you much. A user might even get the idea,
> that he can link /usr/X to /usr/Xgnome2  ... ;-)

Erm, no, not /usr/Xgnome, but /usr/X11, and the gnome and kde bits 
going into that, binaries into /usr/X11/bin, resources into 
/usr/X11/lib/{X11,gnome,...}/app-defaults etc.. I meant the <suffix> 
giving  rise to X11R6, X11R7, X12 ..., and the gnome and KDE stuff 
going into the one they work with together.

In particular, that means a test version of KDE could go into 
/usr/X11beta (say), into which the admin could just duplicate the 
base /usr/X11 tree, then install the test desktop. Whenever there is
another test version, that tree can be summarily discarded. Admins
like that kind of clarity, and few would now fret to have X apps in
/usr/X11beta getting their helper files etc. out of /usr/X11, because
that is what is compiled in. Yes it is a waste of disk space. At least
$0.5 worth of it ...

> I prefer to have the required stuff for a certain DE below one directory
> only. Spreading it around makes it more complicated to maintain and
> export it to other clients ... Also changing the default DE e.g.
> by linking /opt/gnome to /opt/gnome2 would not be easy, at least not,
> if the appropriate links are not in /opt/gnome2 are as well. But if
> you have the links there, why not directly store that stuff over there?

We had that discussion before and we will no doubt have it again. Having 
"all the stuff used together in one directory" works only for apps which
do not integrate with other things. If it is /usr/gnome, /usr/gnome2,
/usr/kde2 and /usr/kde3, and users want to try if their existing 
spreadsheets work with the new stuff while knowing the existing 
presentations do not work with the new processor, there is a vast 
amount of complexity in PATH order to manage. For /opt it is even 
more difficult, as applications from different vendors go into their 
own /opt/<namespace> bit, with not even an attempt at integration.

                                Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)
*   fax:   +4420-7594-6958
*   snail: Thomas Sippel - Dau
*          Linux Services Manager
*          Unix Support Group
*          Information and Communication Technologies
*          Imperial College of Science, Technology and Medicine
*          Exhibition Road
*          Kensington SW7 2BX
*          Great Britain

> -----Original Message-----
> From: Thomas Sippel - Dau [mailto:t.sippel-dau@...]
> 
> Jens Elkner wrote:
> > 
> > > From: Thomas Sippel - Dau [mailto:t.sippel-dau@...]
> > >
> > >    o  tell people to put "desktop related stuff" like kde, gnome
> > >       etc. into /usr/X11, and migrate the name to /usr/X<suffix>
> > 
> > OK. kde, gnome, etc. is usually X-related stuff, but IMHO prefixing
> > them with an X doesn't give you much. A user might even get 
> the idea,
> > that he can link /usr/X to /usr/Xgnome2  ... ;-)

You're right that KDE and Gnome are X11 related. BUT: X11 is definitly NOT
KDE and NOT Gnome related. On my servers, I don't have a graphic display
hence No X11 server so I like to savely remove the .../X11 stuff.

> 
> Erm, no, not /usr/Xgnome, but /usr/X11, and the gnome and kde bits 
> going into that, binaries into /usr/X11/bin, resources into 
> /usr/X11/lib/{X11,gnome,...}/app-defaults etc.. I meant the <suffix> 
> giving  rise to X11R6, X11R7, X12 ..., and the gnome and KDE stuff 
> going into the one they work with together.

Nice point: .../X11R6/... .../X11R9/...
How about .../KDE2/... and .../KDE3/...?

> 
> In particular, that means a test version of KDE could go into 
> /usr/X11beta (say), into which the admin could just duplicate the 
> base /usr/X11 tree, then install the test desktop. Whenever there is

Beta releases are definitly not worth the install in /usr since OS-distro's
should not rely on beta software and hence not bunlde it. Beta releases
definitly go in the /opt area like /opt/X11beta or such. (If they are FHS
compliant ;-)

> another test version, that tree can be summarily discarded. Admins
> like that kind of clarity, and few would now fret to have X apps in
> /usr/X11beta getting their helper files etc. out of /usr/X11, because
> that is what is compiled in. Yes it is a waste of disk space. At least
> $0.5 worth of it ...

Beta's are always a waste of diskspace: it's the choice between the
diskspace, relyability, redundancy, security and added functionallity (add
other reasons to use beta software here).

> 
> > I prefer to have the required stuff for a certain DE below 
> one directory
> > only. Spreading it around makes it more complicated to maintain and
> > export it to other clients ... Also changing the default DE e.g.
> > by linking /opt/gnome to /opt/gnome2 would not be easy, at 
> least not,
> > if the appropriate links are not in /opt/gnome2 are as well. But if
> > you have the links there, why not directly store that stuff 
> over there?
> 
> We had that discussion before and we will no doubt have it 
> again. Having 
> "all the stuff used together in one directory" works only for 
> apps which
> do not integrate with other things. If it is /usr/gnome, /usr/gnome2,
> /usr/kde2 and /usr/kde3, and users want to try if their existing 
> spreadsheets work with the new stuff while knowing the existing 
> presentations do not work with the new processor, there is a vast 
> amount of complexity in PATH order to manage. For /opt it is even 
> more difficult, as applications from different vendors go into their 
> own /opt/<namespace> bit, with not even an attempt at integration.

I've written before, gnome and kde should default to /opt/... too! There
they have their own playground in which they can include or exclude other
apps. Say a new KDE-spreadsheet app should default to /opt/KDE-spreadsheet/
and can be included in /opt/KDE3 by the KDE distro.

It's only the OS-distro that can default ot /usr/... (or even /... for
dedicated apps) and include other packages and apps in there. Then, the
OS-distro can also use /opt/package and hence say "this package is
distributed with the OS but don't regard it as bundled with the OS."

For all packages and applications I say they must have propper relocation
algorithms: Default to install in /opt/app or /opt/package, expect other
apps to be found in /opt/other-app, /usr/local or /usr (or even
/usr/other-app) and be able to relocate to those directories too.

Now I think of it, if apps are not installed in /usr/bin, the installer can
(optionally) create softlinks from /usr/... to the actual installation
location for the frequently called apps. For example GCC should default to
/opt/gcc and create a softlink from /usr/bin/gcc to /opt/bin/gcc. So simple
users don't need /opt/gcc/bin in their $PATH but heavy-duty users can
include /opt/gcc/bin in their $PATH to have better access to dedicated
binaries in there.

my 2 cents

CBee

On Mon, 21 Oct 2002, Thomas Sippel - Dau wrote:

> Jens Elkner wrote:
> > 
> > > From: Thomas Sippel - Dau [mailto:t.sippel-dau@...]
> > >
> > >    o  tell people to put "desktop related stuff" like kde, gnome
> > >       etc. into /usr/X11, and migrate the name to /usr/X<suffix>
> > 
> > OK. kde, gnome, etc. is usually X-related stuff, but IMHO prefixing
> > them with an X doesn't give you much. A user might even get the idea,
> > that he can link /usr/X to /usr/Xgnome2  ... ;-)
> 
> Erm, no, not /usr/Xgnome, but /usr/X11, and the gnome and kde bits 
> going into that, binaries into /usr/X11/bin, resources into 
> /usr/X11/lib/{X11,gnome,...}/app-defaults etc.. I meant the <suffix> 
> giving  rise to X11R6, X11R7, X12 ..., and the gnome and KDE stuff 
> going into the one they work with together.
> 
> In particular, that means a test version of KDE could go into 
> /usr/X11beta (say), into which the admin could just duplicate the 
> base /usr/X11 tree, then install the test desktop. Whenever there is
> another test version, that tree can be summarily discarded. Admins
> like that kind of clarity, and few would now fret to have X apps in
> /usr/X11beta getting their helper files etc. out of /usr/X11, because
> that is what is compiled in. Yes it is a waste of disk space. At least
> $0.5 worth of it ...

Well, as an ADMIN, I love clarity.  I have been forced to install the full 
X package on some servers, just to be able to run a couple of client 
applications on the server.

What I would like is something like this:

	/usr/X -> /usr/X11currentversion
	/usr/X11currentversion contains minimum needed to run X clients

Get that?  Clients only.  Now, as an option on a workstation I would like
to see something like

	/usr/xdt (dt, desktop, Xserver, you-pick-a-name) 
		this contains stuff needed to minimally get the desktop
		running, including
		-> /opt/default-window-env

Add to that an envirionmental variable:   WINENV = /opt/optional-window-env

As an ADMIN, I run (arbitrary example command name) 'chkwinconfig --list'
to see what optional window environments are available - kde, kde3, gnome,
gnome2, etc.... and 'chkwinconfig --default kde3' to adjust the
appropriate links under /usr/you-pick-a-name to change the default
server for the system.

Summary:
	/usr/X - minimal stuff needed to run clients
	/usr/XDT - additional stuff needed to run a server

Bob

Bob Van Cleef <vancleef@...> wrote:
> I have been forced to install the full X package on some servers,
> just to be able to run a couple of client applications on the
> server.

Have the maintainers of your X implementation documented which files
are needed for your purposes?  If so, read those docs.  If not, send a
documentation bug report.  Once you know which files you don't need,
you can remove them, ragardless of whether they happen to be in the
same directory as files you do need.


paul

Bob Van Cleef wrote:
> 
> Well, as an ADMIN, I love clarity.  I have been forced to install the full
> X package on some servers, just to be able to run a couple of client
> applications on the server.
> 
> What I would like is something like this:
> 
>         /usr/X -> /usr/X11currentversion
>         /usr/X11currentversion contains minimum needed to run X clients
> 
> Get that?  Clients only.  Now, as an option on a workstation I would like
> to see something like
> 
>         /usr/xdt (dt, desktop, Xserver, you-pick-a-name)
>                 this contains stuff needed to minimally get the desktop
>                 running, including
>                 -> /opt/default-window-env
> 
> Add to that an envirionmental variable:   WINENV = /opt/optional-window-env
> 
> As an ADMIN, I run (arbitrary example command name) 'chkwinconfig --list'
> to see what optional window environments are available - kde, kde3, gnome,
> gnome2, etc.... and 'chkwinconfig --default kde3' to adjust the
> appropriate links under /usr/you-pick-a-name to change the default
> server for the system.
> 
> Summary:
>         /usr/X - minimal stuff needed to run clients
>         /usr/XDT - additional stuff needed to run a server


Where we come back to package managers again. The FHS promotes an 
"integrated" (or "scattered") use of /usr. This has a strong unifying 
effect, there is "the" version of ls, awk, date and so on. "Improvements" 
are to some extend  impossible, particularly if they are meant to be 
"compatible" (i.e. work for the same circumstances in which the replaced 
product worked), or even "bug compatible" (i.e. fail in the same situations 
in which the replaced version failed).

Bypassing the "normal" version is possible, but requires eternal vigilance.
This unifying effect can feel like a straightjacket to some, and the last
homely house of sanity to others.

Where X-windows is concerned, it needs the clients and library at the back
end, the server at the desktop, and fonts, middleware (like LBX) and other 
resources at either or both ends.

So I fear we have to refer Bob to package managers for his particular 
problem in this case. 

                                Thomas

*   Why not use metric units and get it right first time, every time ?
*
*   email: cmaae47 @ imperial.ac.uk
*   voice: +4420-7594-6912 (day)
*   fax:   +4420-7594-6958
*   snail: Thomas Sippel - Dau
*          Linux Services Manager
*          Unix Support Group
*          Information and Communication Technologies
*          Imperial College of Science, Technology and Medicine
*          Exhibition Road
*          Kensington SW7 2BX
*          Great Britain

Sorry for my ignorance but:

1) I have no idea what the process for updating the FHS is?
2) It seems like this mail thread will not result in a change/addition to FHS,
    like /usr/<foo> for desktop location
3) So we, given our existing constraints, have to go with /usr/* for delivery
    of the desktop with the OS (i.e. bundled with the OS).

Anyway, thanks to all who offered their opinion and advice.

Nils

> -----Original Message-----
> From: Nils Pedersen [mailto:n.p@...]
> 
> Sorry for my ignorance but:

Sorry for my previous (maybe flame like) messages, I did not recognize the
origional message came from the OS distributor Sun. And I did not see any
reason.

> 
> 1) I have no idea what the process for updating the FHS is?

I think that asking for one detailed description (like asking for
/usr/gnome) cannot get it into FHS. I think you make a better chance if you
opt for /usr/<bundle> as an alternate location for OS-Distributors.

> 2) It seems like this mail thread will not result in a 
> change/addition to FHS,
>     like /usr/<foo> for desktop location

I think it should not be any <foo> that can be made available there. I think
it should be clear to  put bundles in there, not single packages or such.
Examples can be /usr/gnome, /usr/kde2 etc. An other reason (and example) is
the already available /usr/X11R6: Adding /usr/<bundle> to the FHS will also
remove the execptional status from the /usr/X11R6.

While adding /usr/<bundle> to FHS, questions rise about the subtree. Shoud
it be like /opt/<package> to include /usr/<bundle>/etc or just use /etc/ or
/etc/<bundle>. Same for all other standardized subdirectories like .../lib
and so on.

> 3) So we, given our existing constraints, have to go with 
> /usr/* for delivery
>     of the desktop with the OS (i.e. bundled with the OS).

For OS distributions, I think they can set examples. 

> Anyway, thanks to all who offered their opinion and advice.

The discussion made me think and maybe a little more wise.


CBee