Hi!

Sean Kendall Schneyer wrote:
> 
> Kurt Granroth wrote:
> >
> [snip]
> 
> > The FHS says to do things like
> >
> > /x/share/kde
> > /x/share/gnome
> > /x/share/vim
> > /x/lib/kde (I think)
> > /x/lib/gnome (I think)
> > /x/bin
> >
> > Personally, I like our $KDEDIR setup the best.  KDE is just too big to think
> > that it can easily fit at the same level as "normal" packages.
> 
> So we are supposed to just disregard the FHS just because you
> think that KDE is too big to be put under the "correct" locations?!?
It's too fine for it as well. :-)

> I'm not very familiar with the standard, but I personally feel that
> if we are going to go agains a set standard that we need to have
> a better reason than "it's just too big". Plus it shouldn't be a

FHS is crap for workstations i think. Yes, it is a standard, but FHS has
been designed years ago where the amount of apps to be stored was
typically small. Nowadays, there are so much apps installed on *nixes,
that the original claimed /usr partition began to grow and grow. You
became /usr/local as well and could use /opt in rare situations, but
anything beyond this had broken and will brake FHS.

Pro FHS is it is a standard and people knowing FHS know where they can
find what. 

But i think FHS is pretty unflexible now. Even for somebody experienced
with FHS it would twice or even more the time to move an existing entire
e.g. fhs-compliant kde installation from /usr to another partition than
a user, having a /x/kde kde-root. It is really hard to backup selective
packages from a FHS compliant installation, for you have to select each
single file of that packages. If you go into /usr/bin (FHS) and look for
a forgotten tool of package x, then an ls won't help; you need an entire
database containing all files of the packages instead, need to seek that
database for that package, print it's contents, grep for /usr/bin and
then you get the binaries. 

> real problem for the user that doesn't want to put it with
> the "normal" packages, then all they have to do is define "x" to
> be /opt or /kde or anything else the user wants.

What about the other way round:
If a user (you?) really wants a FHS compliant installation, he could
have a look into the debian/ directory of the kde sources. :-)


Regards,
  Holger