> -----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
|