[gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Thomas Weidner]

Hi,

I think all know /usr/qt and /usr/kde conflicts with the FHS, but it's
there in order to make it possible to have several versions of kde/qt
installed side by side. If there was a way to make qt and kde
installations FHS compilant without removing the possibility to have
several versions installed side by side,whould there be any interest to
add it to portage or want gentoo developers to stick with the current
solution? I know the current version works, but it conflicts with the
FHS (and therefore with the LSB).

	Thomas Weidner


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Sun, 19 Sep 2004 21:50:46 +0200 Thomas Weidner <3.14159@gmx.net>
wrote:
| I know the current version works, but it conflicts
| with the FHS (and therefore with the LSB).

LSB compliance isn't exactly high on our list of priorities... FHS,
maybe, but definitely not LSB.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

On Sunday 19 September 2004 22:50, Thomas Weidner wrote:
> Hi,
>
> I think all know /usr/qt and /usr/kde conflicts with the FHS, but it's
> there in order to make it possible to have several versions of kde/qt
> installed side by side. If there was a way to make qt and kde 
> installations FHS compilant without removing the possibility to have
> several versions installed side by side,whould there be any interest to
> add it to portage or want gentoo developers to stick with the current
> solution? I know the current version works, but it conflicts with the
> FHS (and therefore with the LSB).

/usr/qt,kde was my decision at the time. I didn't see any obvious better 
FHS-mandated place to put them in. If there's a better place, I'd at least 
like to hear about it.

If it's a matter of simply moving the /usr/{qt,kde}/$VERSION directories 
anywhere else, that's as simple as setting a few env variables before an 
emerge, and changing their default vaules in eclasses or whereever.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Mike Frysinger]

On Sunday 19 September 2004 03:52 pm, Ciaran McCreesh wrote:
> LSB compliance isn't exactly high on our list of priorities... FHS,
> maybe, but definitely not LSB.

LSB is much more than a filesystem spec which is why we dont bend over 
backwards for it, but FHS is something we try for

and yes, the way we install KDE/QT fly in the face of FHS ... but it does 
allow us to easily SLOT kde versions ...
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Joshua J. Berry]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote:
> 
> /usr/qt,kde was my decision at the time. I didn't see any obvious better 
> FHS-mandated place to put them in. If there's a better place, I'd at least 
> like to hear about it.

Why /usr instead of /opt?

Based on my recollection of the FHS, it seems like /opt would be the better
place to put it ...

-- 
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Sunday 19 September 2004 22:06, Dan Armak wrote:
> /usr/qt,kde was my decision at the time. I didn't see any obvious better
> FHS-mandated place to put them in. If there's a better place, I'd at least
> like to hear about it.
>
> If it's a matter of simply moving the /usr/{qt,kde}/$VERSION directories
> anywhere else, that's as simple as setting a few env variables before an
> emerge, and changing their default vaules in eclasses or whereever.

I'm also still not convinced that this is really against the FHS. I think this 
could be a border case that just falls in or out the FHS. The FHS forbids 
direct children directories of /usr, but /usr/kde/3.3 is not a direct child. 
Maybe it is not in the exact spirit of FHS, but as far as I know the FHS 
people have also not offered any sensible solution for kde, qt etc. yet. They 
also DO NOT belong in /opt, as they are not standalone packages (let alone 
binary which is the gentoo requirement (sort of))

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Sun, 19 Sep 2004 13:07:37 -0700 "Joshua J. Berry"
<condordes@gentoo.org> wrote:
| On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote:
| > 
| > /usr/qt,kde was my decision at the time. I didn't see any obvious
| > better FHS-mandated place to put them in. If there's a better place,
| > I'd at least like to hear about it.
| 
| Why /usr instead of /opt?

Because /opt is evil, especially for things we're building ourselves.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Sunday 19 September 2004 23:07, Joshua J. Berry wrote:
> On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote:
> > /usr/qt,kde was my decision at the time. I didn't see any obvious better
> > FHS-mandated place to put them in. If there's a better place, I'd at
> > least like to hear about it.
>
> Why /usr instead of /opt?
Quoting FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.html):
"Purpose: /opt is reserved for the installation of add-on application software 
packages."

To this day I haven't heard a good definitin of "add-on" software in this 
context. I don't see qt/kde as being an addon to anything else.

Moreover, as Paul points out, in Gentoo we only use /opt so far for 
binary-only packages and for packages that don't obey the general unix 
directory structur (/bin, /lib, /share, /include...). qt/kde has neither of 
these characteristics.

The FHS says about /usr: "Large software packages must not use a direct 
subdirectory under the /usr hierarchy." I agree this rules out what we're 
doing. The problem is, noone ever proposed a better (more FHS-compliant) 
solution.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Joshua J. Berry]

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

On Sun, Sep 19, 2004 at 11:16:44PM +0300, Dan Armak wrote:
> On Sunday 19 September 2004 23:07, Joshua J. Berry wrote:
> > On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote:
> > > /usr/qt,kde was my decision at the time. I didn't see any obvious better
> > > FHS-mandated place to put them in. If there's a better place, I'd at
> > > least like to hear about it.
> >
> > Why /usr instead of /opt?
> Quoting FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.html):
> "Purpose: /opt is reserved for the installation of add-on application software 
> packages."
> 
> To this day I haven't heard a good definitin of "add-on" software in this 
> context. I don't see qt/kde as being an addon to anything else.

I could easily see KDE/Qt being treated as an "add-on", given that (a) they're
not necessary for core system functionality (whatever that means), and (b) they
are both heavily-bloated, and you probably don't want to pollute /usr...

> Moreover, as Paul points out, in Gentoo we only use /opt so far for 
> binary-only packages and for packages that don't obey the general unix 
> directory structur (/bin, /lib, /share, /include...). qt/kde has neither of 
> these characteristics.

This is true, but I'm wondering if that's maybe a silly move on our part, for
just this reason.

> The FHS says about /usr: "Large software packages must not use a direct 
> subdirectory under the /usr hierarchy." I agree this rules out what we're 
> doing. The problem is, noone ever proposed a better (more FHS-compliant) 
> solution.

I really do think this is what /opt was intended for.  "Add-on" sounds to me
like it's one of those purposefully open-ended words that you can interpret
however you like.  Actually, the whole section on /opt in the FHS reads that way
...

-- 
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

On Sun, 19 Sep 2004 13:26:01 -0700 "Joshua J. Berry"
<condordes@gentoo.org> wrote:
| > To this day I haven't heard a good definitin of "add-on" software in
| > this context. I don't see qt/kde as being an addon to anything else.
| 
| I could easily see KDE/Qt being treated as an "add-on", given that (a)
| they're not necessary for core system functionality (whatever that
| means), and (b) they are both heavily-bloated, and you probably don't
| want to pollute /usr...

They're installed by the package manager. They are therefore not add-on.

| I really do think this is what /opt was intended for.  "Add-on" sounds
| to me like it's one of those purposefully open-ended words that you
| can interpret however you like.  Actually, the whole section on /opt
| in the FHS reads that way...

No, /opt was intended as a temporary place for Sun to stick things until
they decided where in /usr they should go. Unfortunately, someone messed
up and /opt became widely used. The conventional non-screwed-up place is
/usr/kde/whatever, but FHS doesn't like this for some bizarre reason.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

On Sunday 19 September 2004 23:26, Joshua J. Berry wrote:
> I could easily see KDE/Qt being treated as an "add-on", given that (a)
> they're not necessary for core system functionality (whatever that means),
Er, so does that mean anything not in the system profile should go in /opt? 
I'd say qt/kde is as important a piece of a dekstop system using it as any 
other.

> and (b) they are both heavily-bloated, 
Bloated in what respect? Size, speed? And what does it have to do with where 
we install them to?

> and you probably don't want to 
> pollute /usr...
It's true that I don't want to, only I don't see a better solution.

If there's a general consensus on moving to /opt I can live with that, because 
it doesn't affect the ebuilds/eclasses/results one bit. It's just that it's 
entirely inconsistent with the way we're using /opt right now. 

And what if, in a year from now, twenty other projects will decide it's good 
for the users to allow many versions to be installed side by side? Will we 
move everything to /opt? My point here is that kde itself is not special in 
any way (although qt arguably is, since you do want different qt2 and qt3 
programs side by side, but then the qt libraries could live together in /usr 
with some effort). It's just that kde users asked for this functionality a 
lot, so I added it. Apart from running two stable trees, kde developers use 
this to run a stable tree and cvs HEAD.

<snip>
> I really do think this is what /opt was intended for.  "Add-on" sounds to
> me like it's one of those purposefully open-ended words that you can
> interpret however you like.  Actually, the whole section on /opt in the FHS
> reads that way ...

Well, I simply don't know what they mean by add-on, so obviously you can 
interpret it however you like :-) 

However, isn't there -any- consensus on what this is supposed to mean? Can we 
just ask the FHS guys if this is so unclear? (And cf. what Ciaran just 
replied.)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Malte S. Stretz]

On Sunday 19 September 2004 22:37 CET Dan Armak wrote:
> On Sunday 19 September 2004 23:26, Joshua J. Berry wrote:
> >[...]
> > I really do think this is what /opt was intended for.  "Add-on" sounds
> > to me like it's one of those purposefully open-ended words that you can
> > interpret however you like.  Actually, the whole section on /opt in the
> > FHS reads that way ...
>
> Well, I simply don't know what they mean by add-on, so obviously you can
> interpret it however you like :-)
>
> However, isn't there -any- consensus on what this is supposed to mean?
> Can we just ask the FHS guys if this is so unclear? (And cf. what Ciaran
> just replied.)

I'll ask Daniel Quinlan what he things when pops online.

But currently each distro does it how the maintainer like it (or interprets 
the FHS) -- Gentoo uses /usr/kde, SuSE /opt/kde, RedHat something else, and 
I think Debian throws all the stuff into /usr.  To me this sounds like the 
FHS is flawed if it comes to stuff like this.  Even the /usr/X11R6 
directory is only there because it was always there though an alternative 
is missing, too.

Ironically was there lately a discussion on the KDE core-devel list if the 
default location for KDE should be /opt/kde for KDE 4 (instead 
of /usr/local).

If something is broken, it's normally the better to fix it instead of 
working around.  So maybe the FHS should be refined to support what is 
needed by either adding an additional subdirectory below /usr or a 
completely new root-level directory.  I mean it's not like the place in / 
is limited by anything and /svc was also added lately (and btw Linux' /sys 
is completely against the FHS).

Another thing which cropped up in combination with the macchanger ebuild 
(the issue is in b.g.o) was that sometimes shomething like /share 
or /lib/share is needed.

The current FHS mailinglist is more a spamtrap than anything.  Maybe a new 
one should be created.  There a group of people consisting of (a) the 
previous FHS contributors (b) somebody from each big distro and (c) some 
people from the bigger desktop environments (or freedesktop.org) can get 
together and try to fix all the current issues with the FHS and create a 
version 3.0.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

On Sunday 19 September 2004 7:50 pm, Thomas Weidner wrote:
> I think all know /usr/qt and /usr/kde conflicts with the FHS, but it's
> there in order to make it possible to have several versions of kde/qt
> installed side by side. If there was a way to make qt and kde
> installations FHS compilant without removing the possibility to have
> several versions installed side by side,whould there be any interest to
> add it to portage or want gentoo developers to stick with the current
> solution? I know the current version works, but it conflicts with the
> FHS (and therefore with the LSB).

IIRC, having /mnt as anything but an empty directory conflicts with the FHS 
also. Gentoo uses /mnt as FHS's /media

On Sunday 19 September 2004 8:16 pm, Dan Armak wrote:
> The FHS says about /usr: "Large software packages must not use a direct
> subdirectory under the /usr hierarchy." I agree this rules out what we're
> doing. The problem is, noone ever proposed a better (more FHS-compliant)
> solution.

So is XFree86/X.org in violation of this also?

On Sunday 19 September 2004 8:37 pm, Dan Armak wrote:
> My point here is that kde itself is not special in any way (although qt
> arguably is, since you do want different qt2 and qt3 programs side by side,
> but then the qt libraries could live together in /usr with some effort).

No need for such versioning of Qt 2 and 3 libs as far as I can tell. Isn't Qt 
3 binary compatible with 2? (note: this will soon change with Qt 4 not being 
compatible with either)
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Joshua J. Berry]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Sun, Sep 19, 2004 at 09:29:40PM +0100, Ciaran McCreesh wrote:
> On Sun, 19 Sep 2004 13:26:01 -0700 "Joshua J. Berry"
> <condordes@gentoo.org> wrote:
> | > To this day I haven't heard a good definitin of "add-on" software in
> | > this context. I don't see qt/kde as being an addon to anything else.
> | 
> | I could easily see KDE/Qt being treated as an "add-on", given that (a)
> | they're not necessary for core system functionality (whatever that
> | means), and (b) they are both heavily-bloated, and you probably don't
> | want to pollute /usr...
> 
> They're installed by the package manager. They are therefore not add-on.

No, that's not the way the FHS interprets "add-on".

"Distributions may install software in /opt, but must not modify or delete
software installed by the local system administrator without the assent of the
local system administrator."

By your logic, Gentoo has no business sticking *anything* in /opt.

I don't think packages in /opt (acroread, sun-jdk, openoffice, et al) violate
the FHS, and if they don't, then I don't see why KDE/Qt in /opt would.

-- 
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Joshua J. Berry]

[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]

On Sun, Sep 19, 2004 at 11:37:55PM +0300, Dan Armak wrote:
> On Sunday 19 September 2004 23:26, Joshua J. Berry wrote:
> 
> > and (b) they are both heavily-bloated, 
> Bloated in what respect? Size, speed? And what does it have to do with where 
> we install them to?

Size (specifically, number of files).  For example:

condor@alnath /usr/kde/3.3/bin> ls |wc -l
368
condor@alnath /usr/kde/3.3/lib> ls |wc -l
733

That could pollute the /usr hierarchy quite a bit, which is why I think moving
it to straight /usr is a bad idea.

> > and you probably don't want to 
> > pollute /usr...
> It's true that I don't want to, only I don't see a better solution.
> 
> If there's a general consensus on moving to /opt I can live with that, because 
> it doesn't affect the ebuilds/eclasses/results one bit. It's just that it's 
> entirely inconsistent with the way we're using /opt right now. 

Perhaps we need to reevaluate how we're using /opt.

I'm fine with the current /usr/kde/<version> scheme, but the FHS says that's a
no-no.  But, they say /opt/<package> is perfectly OK for "add-on" software.

From an FHS perspective, the only question is whether or not KDE constitutes
"add-on" software.  We could have a flamewar on that question for the next 10
years and not get anywhere. ;)

> And what if, in a year from now, twenty other projects will decide it's good 
> for the users to allow many versions to be installed side by side? Will we 
> move everything to /opt? My point here is that kde itself is not special in 
> any way (although qt arguably is, since you do want different qt2 and qt3 
> programs side by side, but then the qt libraries could live together in /usr 
> with some effort). It's just that kde users asked for this functionality a 
> lot, so I added it. Apart from running two stable trees, kde developers use 
> this to run a stable tree and cvs HEAD.

No, it's not special, but I think most people probably won't want a PATH
variable that's 10,000 directories long. ;)  The only thing that makes it
"special" IMHO is how big it is.

For smaller packages, it would probably just be easier to do something similar
to what we do right now for GIMP and rename the binaries (you're only talking a
few, not hundreds as would be the case with KDE).

-- 
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Thomas Weidner]

Luke-Jr wrote:
  > IIRC, having /mnt as anything but an empty directory conflicts with 
the FHS
> also. Gentoo uses /mnt as FHS's /media
/mnt : Mount point for a temporarily mounted filesystem
Purpose

This directory is provided so that the system administrator may 
temporarily mount a filesystem as needed. The content of this directory 
is a local issue and should not affect the manner in which any program 
is run.

This directory must not be used by installation programs: a suitable 
temporary directory not in use by the system must be used instead.

> On Sunday 19 September 2004 8:16 pm, Dan Armak wrote:
> 
>>The FHS says about /usr: "Large software packages must not use a direct
>>subdirectory under the /usr hierarchy." I agree this rules out what we're
>>doing. The problem is, noone ever proposed a better (more FHS-compliant)
>>solution.
> 
> 
> So is XFree86/X.org in violation of this also?

FHS says about /usr/X11R6: ``An exception is made for the X Window 
System because of considerable precedent and widely-accepted practice.''
So it's an exception, _not_ the rule. (pls don't start to ask if kde/qt 
can also be an exception...not it can not imo)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Armando Di Cianno]

Some questions, and my $0.02 ...

>>> I really do think this is what /opt was intended for.  "Add-on" 
>>> sounds
>>> to me like it's one of those purposefully open-ended words that you 
>>> can
>>> interpret however you like.  Actually, the whole section on /opt in 
>>> the
>>> FHS reads that way ...
...
> But currently each distro does it how the maintainer like it (or 
> interprets 
> the FHS) -- Gentoo uses /usr/kde, SuSE /opt/kde, RedHat something 
> else, and I 
> think Debian throws all the stuff into /usr.  To me this sounds like 
> the FHS 
> is flawed if it comes to stuff like this.  Even the /usr/X11R6 
> directory is 
> only there because it was always there though an alternative is 
> missing, too.

So, I'm taking care of bringing a usable GNUstep system into portage.  
(Anyone following this: I'm pretty much waiting for another stable 
release of -gui, as to not litter portage with cvs-pull-and-tar 
ebuilds, before uploading anything...).

GNUstep has classically been installed into /usr/GNUstep, which would 
obviously violate the FHS.  The thing is, imho, the FHS is for 
UNIX/UNIX-like systems, while GNUstep just-so-happens to be a system 
that can run on top of UNIX/UNIX-like systems (as well as Windows, OS 
X, etc).  All that is required is a "root" to place it's base, and any 
other run-time created files can be bridged into the FHS as 
appropriate.

The problem is, that quite like X11, the hierarchy under .../GNUstep 
is different from the rest of the FHS recommended directories, 
reflecting the fact that GNUstep is not UNIX.  I'd happily use /opt, 
but that seems rather non-Gentoo, atm.

I'll be following this thread, and will likely follow recommendations, 
as applicable, that are made for qt or kde.  Keep in mind that GNUstep 
is "a whole other system" and not just a "set of libraries and 
programs".  Any specific recommendations about what I should do 
concerning GNUstep would also be greatly appreciated.

Thanks for keeping this in mind,
__armando




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Sunday 19 September 2004 11:06 pm, Thomas Weidner wrote:
> Luke-Jr wrote:
>   > IIRC, having /mnt as anything but an empty directory conflicts with the
>   > FHS also. Gentoo uses /mnt as FHS's /media
>
> /mnt : Mount point for a temporarily mounted filesystem
> Purpose
>
> This directory is provided so that the system administrator may
> temporarily mount a filesystem as needed. The content of this directory
> is a local issue and should not affect the manner in which any program
> is run.
>
> This directory must not be used by installation programs: a suitable
> temporary directory not in use by the system must be used instead.

Exactly. For a *system administrator* to *temporarily* mount a filesystem in. 
This means 'mount some-temp-filesystem /mnt' temporarily, not 
'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0 /mnt/floppy; etc' perminantly.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Mon, 20 Sep 2004 00:03:59 +0000 Luke-Jr <luke-jr@utopios.org> wrote:
| Exactly. For a *system administrator* to *temporarily* mount a
| filesystem in. This means 'mount some-temp-filesystem /mnt'
| temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0
| /mnt/floppy; etc' perminantly.-- 

Why have a specific toplevel for that? No need, just use cwd or $HOME.
Surely you don't think the FHS is thaaaaat silly? By 'temporary' they've
gotta mean 'not always mounted'. Anything else is madness.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

On Monday 20 September 2004 12:55 am, Ciaran McCreesh wrote:
> On Mon, 20 Sep 2004 00:03:59 +0000 Luke-Jr <luke-jr@utopios.org> wrote:
> | Exactly. For a *system administrator* to *temporarily* mount a
> | filesystem in. This means 'mount some-temp-filesystem /mnt'
> | temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0
> | /mnt/floppy; etc' perminantly.--
>
> Why have a specific toplevel for that? No need, just use cwd or $HOME.
> Surely you don't think the FHS is thaaaaat silly?

If the LSB can be silly enough to require RPM, why can't the FHS be silly 
enough to require a silly toplevel?

> By 'temporary' they've gotta mean 'not always mounted'.

And they do... However, the mount point is /mnt, not /mnt/*
Also, on many systems, /mnt/cdrom etc *are* always mounted ... as 
supermount. :)

> Anything else is madness. 
No comment.
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Monday 20 September 2004 01:35, Joshua J. Berry wrote:
> No, it's not special, but I think most people probably won't want a PATH
> variable that's 10,000 directories long. ;)  The only thing that makes it
> "special" IMHO is how big it is.
That isn't affected by our choice of /usr/kde or /opt. 10,000 PATH dirs 
under /opt are equally as bad. So I don't see your point here? Is it that you 
want to decrease the sheer amount of files in the /usr filesystem? As far as 
I'm concerned, all portage-installed packages ought to go in /usr except for 
those that go in /bin /lib etc; the usage of /opt has so far meant the 
package was lacking in some respect.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Mike Frysinger]

On Monday 20 September 2004 12:10 am, Dan Armak wrote:
> the usage of /opt has so far
> meant the package was lacking in some respect.

no, the gentoo policy of putting binary-only packages in /opt is by no means a 
portage limitation
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Luke-Jr]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

On Monday 20 September 2004 4:27 am, Mike Frysinger wrote:
> no, the gentoo policy of putting binary-only packages in /opt is by no
> means a portage limitation
Just a note, it's binary packages in /opt, not merely binary-only... 
mozilla-bin, openoffice-bin, etc certainly aren't binary-*only*...
-- 
Luke-Jr
Developer, Utopios
http://utopios.org/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Joshua J. Berry]

[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]

On Mon, Sep 20, 2004 at 07:10:02AM +0300, Dan Armak wrote:
> On Monday 20 September 2004 01:35, Joshua J. Berry wrote:
> > No, it's not special, but I think most people probably won't want a PATH
> > variable that's 10,000 directories long. ;)  The only thing that makes it
> > "special" IMHO is how big it is.
> That isn't affected by our choice of /usr/kde or /opt. 10,000 PATH dirs 
> under /opt are equally as bad. So I don't see your point here? 

Assuming I understood you correctly, you made the point that if KDE goes into
/opt and gets its own directory, others might want to do that too ...

My point is that KDE should be an exception to the
"packages-shouldn't-have-their-own-dirs" rule because it's so big.

> Is it that you 
> want to decrease the sheer amount of files in the /usr filesystem? 

I would like to keep the pollution in /usr down, yes.

> As far as 
> I'm concerned, all portage-installed packages ought to go in /usr except for 
> those that go in /bin /lib etc; the usage of /opt has so far meant the 
> package was lacking in some respect.

I don't know.  Maybe it makes more sense to me because that's just always the
way I've installed KDE -- separate from everything else.  I can see the benefits
of the "everything-in-/usr" argument too (pollution notwithstanding).

It seems like a lot of people prefer to have Qt/KDE split out from the normal
/usr tree.  But some people are complaining because /usr/kde doesn't follow the
FHS.

/opt keeps both groups happy.  It keeps KDE separate (and lets you install
multiple versions side-by-side), and it follows the FHS.  Except now we have a
third group of people who don't like /opt ... and I guess I don't understand why
that is.  What do people have against /opt (yes, I know about current Gentoo
policy)?

-- 
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Simon Watson]

Dan Armak wrote:
> The FHS says about /usr: "Large software packages must not use a direct 
> subdirectory under the /usr hierarchy." I agree this rules out what we're 
> doing. The problem is, noone ever proposed a better (more FHS-compliant) 
> solution.
> 

How about a USE flag or such like, for specifying FHS compliancy? 
Whereby if specified QT/KDE would be installed as per FHS, but with a 
warning that this means SLOTting no longer works?

Simon

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

On Monday 20 September 2004 00:23, Joshua J. Berry wrote:
>
> No, that's not the way the FHS interprets "add-on".
>
> "Distributions may install software in /opt, but must not modify or
> delete software installed by the local system administrator without the
> assent of the local system administrator."
>
> By your logic, Gentoo has no business sticking *anything* in /opt.
>
> I don't think packages in /opt (acroread, sun-jdk, openoffice, et al)
> violate the FHS, and if they don't, then I don't see why KDE/Qt in /opt
> would.

The big difference is there are many packages that actively depend on kde. 
While all those other packages can be seen as "self-contained". They are 
leaf nodes in the dependency tree. Kde certainly isn't (well, kdelibs and 
kdebase at least).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2517 bytes --]

On Sunday 19 September 2004 23:23, Malte S. Stretz wrote:
> But currently each distro does it how the maintainer like it (or
> interprets the FHS) -- Gentoo uses /usr/kde, SuSE /opt/kde, RedHat
> something else, and I think Debian throws all the stuff into /usr.  To
> me this sounds like the FHS is flawed if it comes to stuff like this. 
> Even the /usr/X11R6 directory is only there because it was always there
> though an alternative is missing, too.
>
> Ironically was there lately a discussion on the KDE core-devel list if
> the default location for KDE should be /opt/kde for KDE 4 (instead of
> /usr/local).
>
> If something is broken, it's normally the better to fix it instead of
> working around.  So maybe the FHS should be refined to support what is
> needed by either adding an additional subdirectory below /usr or a
> completely new root-level directory.  I mean it's not like the place in
> / is limited by anything and /svc was also added lately (and btw Linux'
> /sys is completely against the FHS).

Welcome to the real world. This is broken for a long long time and I'm 
sure that it was mentioned to the FHS people a long time ago.

>
> Another thing which cropped up in combination with the macchanger
> ebuild (the issue is in b.g.o) was that sometimes shomething like
> /share or /lib/share is needed.
>
> The current FHS mailinglist is more a spamtrap than anything.  Maybe a
> new one should be created.  There a group of people consisting of (a)
> the previous FHS contributors (b) somebody from each big distro and (c)
> some people from the bigger desktop environments (or freedesktop.org)
> can get together and try to fix all the current issues with the FHS and
> create a version 3.0.

When the FHS gets sensible enough to offer a solution for existing 
problems then I'm surely in favour of following it, but as it stands the 
FHS does not answer some of the questions we have.

Paul

ps. The other "solution" could be to do it like the eclipse ebuild does 
and install in /usr/lib/eclipse or /usr/lib/kde/3.3, although I even like 
it less. I think that our solution is best. To be FHS compliant (better, 
to sidestep the FHS) we could make a new subdir to /usr where we put 
these packages. This does not violate the FHS as no package is directly 
under /usr and we still follow our own guidelines, and provide a clean 
solution.


-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On Monday 20 September 2004 08:09, Joshua J. Berry wrote:

> /opt keeps both groups happy.  It keeps KDE separate (and lets you
> install multiple versions side-by-side), and it follows the FHS. 
> Except now we have a third group of people who don't like /opt ... and
> I guess I don't understand why that is.  What do people have against
> /opt (yes, I know about current Gentoo policy)?

There are two reasons:
- It is against gentoo policy
- It is against the FHS as KDE is not a standalone package, but it has a
  significant amount of dependant packages. One of the rules for /opt is
  that no package in /usr should depend on it. As dependend packages are
  installed in /usr this is clearly a violation.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Malte S. Stretz]

On Monday 20 September 2004 10:48 CET Paul de Vrieze wrote:
> On Sunday 19 September 2004 23:23, Malte S. Stretz wrote:
> >[...]
> > If something is broken, it's normally the better to fix it instead of
> > working around.  So maybe the FHS should be refined to support what is
> > needed by either adding an additional subdirectory below /usr or a
> > completely new root-level directory.  I mean it's not like the place in
> > / is limited by anything and /svc was also added lately (and btw Linux'
> > /sys is completely against the FHS).
>
> Welcome to the real world. This is broken for a long long time and I'm
> sure that it was mentioned to the FHS people a long time ago.

Yes, I know.  But I don't understand why it isn't fixed then.  Ok, I already 
had some lengthy discussions with Daniel Quinlan about stuff like this (the 
other guys I don't know) but in the end we always^Wmostly managed to come 
to a sensible solution.

What I don't get is that the FHS is clearly flawed (if not by design then at 
least the wording could be clearer) and that is known for years.  So people 
had quite some time to find the problems with the current version but 
instead of gathering and working on a fixed version everybody mumbles "bah, 
FHS sucks, we do it how we interpret it" and goes on.  For the last few 
years I read threads like this one at least twice per year on various 
mailinglists or websites.

I don't propose to create something completely new like, say, what Apple 
uses in MacOS X, just to refine the current state of art.  As I said, it's 
not like we lack space in / or need to look like a "real" SysV system.  
Linux (or GNU/Linux if you prefer that) is IMO about invention, so why do 
we try to cram everything into the olde Unix directory structure while it 
obviously doesn't fit?

> > Another thing which cropped up in combination with the macchanger
> > ebuild (the issue is in b.g.o) was that sometimes shomething like
> > /share or /lib/share is needed.
> >
> > The current FHS mailinglist is more a spamtrap than anything.  Maybe a
> > new one should be created.  There a group of people consisting of (a)
> > the previous FHS contributors (b) somebody from each big distro and (c)
> > some people from the bigger desktop environments (or freedesktop.org)
> > can get together and try to fix all the current issues with the FHS and
> > create a version 3.0.
>
> When the FHS gets sensible enough to offer a solution for existing
> problems then I'm surely in favour of following it, but as it stands the
> FHS does not answer some of the questions we have.

My point is that the FHS won't get any better if people don't get together 
and fix it.  Of course can we continue to curse the FHS 2.x for the next 
ten years but how productive is that?

> ps. The other "solution" could be to do it like the eclipse ebuild does
> and install in /usr/lib/eclipse or /usr/lib/kde/3.3, although I even like
> it less. 

That's actually what KDE is aiming for for version 4 (and AFAIK what GNOME 
already uses).  And apart from that, Qt most probably belongs 
to /usr/lib/qt.

> I think that our solution is best. To be FHS compliant (better, 
> to sidestep the FHS) we could make a new subdir to /usr where we put
> these packages. This does not violate the FHS as no package is directly
> under /usr and we still follow our own guidelines, and provide a clean
> solution.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

On Monday 20 September 2004 11:48, Paul de Vrieze wrote:
> ps. The other "solution" could be to do it like the eclipse ebuild does
> and install in /usr/lib/eclipse or /usr/lib/kde/3.3, although I even like
> it less. I think that our solution is best. To be FHS compliant (better,
> to sidestep the FHS) we could make a new subdir to /usr where we put
> these packages. This does not violate the FHS as no package is directly
> under /usr and we still follow our own guidelines, and provide a clean
> solution.

Since the issue's been raised, I've nothing against this proposal. We want to 
counter the possible future problem of other packages following kde's lead 
and supporting multiple versions in separate directories, because many 
directories under /usr really is messy.

 E.g., create a /usr/packages and put qt, kde and anything else there 
(/usr/packages/kde/3.2; ...). Who wants to take this proposal to the FHS 
people? :-)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Sami Samhuri]

[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]

* On Sun Sep-19-2004 at 11:09:36 PM -0700, Joshua J. Berry said:
> On Mon, Sep 20, 2004 at 07:10:02AM +0300, Dan Armak wrote:
> 
> > Is it that you 
> > want to decrease the sheer amount of files in the /usr filesystem? 
> 
> I would like to keep the pollution in /usr down, yes.

Why? (Not trolling, just genuinely curious.) Do you mean KDE being in
/usr at all, or just not in /usr/kde/?

I think it makes sense to keep it under /usr, where everything else is
installed. I'd rather not have packages installed in /opt at all.

Granted, I think there could be a better solution (I don't like package
subdirs directly under /usr either) but I don't think /opt is it.

/opt conveys nothing to me. /usr/prog, /usr/app, /usr/soft, it's hard to
think of a meaningful name that's not more than 4 chars, but I think
that's a good solution. A symlink from /usr/bin/kde to
/usr/XXX/kde/3.3/bin would take care of the $PATH problem, I think.

Sorry for jumping in, and sorry if I've said something ridiculous here.
I'm new to Gentoo but this interests me.

-- 
Sami Samhuri

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Armando Di Cianno]

On 2004-09-20 05:47:18 -0400 Malte S. Stretz 
<msquadrat.nospamplease@gmx.net> wrote:
> I don't propose to create something completely new like, say, what 
> Apple uses 
> in MacOS X, just to refine the current state of art.  As I said, it's 
> not 
> like we lack space in / or need to look like a "real" SysV system.  
> Linux (or 
> GNU/Linux if you prefer that) is IMO about invention, so why do we 
> try to 
> cram everything into the olde Unix directory structure while it 
> obviously 
> doesn't fit?

Just to be ontologically aligned with those that created the NeXTStep 
hierarchy, OS X (NeXTStep/OpenStep's logical descendants [alongside 
GNUstep]) has it's own UNIX-y/FHS-y hierarchy, from the BSD tools, 
_and_ a NeXT-y hierarchy.

I chimed in before about what I should do with GNUstep, but whereever 
in the UNIX-y hierarchy it lives, it's packages are going to be 
installed underneath it, e.g /opt/GNUstep, /usr/GNUstep, etc.  
Classically, on UNIX-y systems ('cause it can run on Windows, too) the 
preferred spot is /usr/GNUstep.  This was likely chosen by the 
original authors thinking "Hey, that's what X11 did...".

This is a concern for me, not because GNUstep is "big" and will cause 
"pollution," but because it is _different_ than what the FHS was 
designed for.

__armando



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Monday 20 September 2004 00:35, Joshua J. Berry wrote:
> On Sun, Sep 19, 2004 at 11:37:55PM +0300, Dan Armak wrote:
> > On Sunday 19 September 2004 23:26, Joshua J. Berry wrote:
> > > and (b) they are both heavily-bloated,
> >
> > Bloated in what respect? Size, speed? And what does it have to do with
> > where we install them to?
>
> Size (specifically, number of files).  For example:
>
> condor@alnath /usr/kde/3.3/bin> ls |wc -l
> 368
> condor@alnath /usr/kde/3.3/lib> ls |wc -l
> 733
>
> That could pollute the /usr hierarchy quite a bit, which is why I think
> moving it to straight /usr is a bad idea.

I get the point with /usr/kde not conforming to FHS, but imho the size of 
packages has nothing to do with their location. The main questions are, if 
the data is variable or static, shared or not. Could you enlight me about 
that?

I don't think that it should go in /opt, since the kde stuff is simply not 
more or less optional as everythin else. I wonder if it would be better to 
have /usr/lib/kde/x.y, /usr/share/kde/x.y,... directories!? 


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Malte S. Stretz]

On Monday 20 September 2004 18:22 CET Carsten Lohrke wrote:
> I get the point with /usr/kde not conforming to FHS, but imho the size of
> packages has nothing to do with their location. The main questions are,
> if the data is variable or static, shared or not. Could you enlight me
> about that?
>
> I don't think that it should go in /opt, since the kde stuff is simply
> not more or less optional as everythin else. I wonder if it would be
> better to have /usr/lib/kde/x.y, /usr/share/kde/x.y,... directories!?

That's actually a good point.  Theoretically its possible to share some 
parts of the system across several machines, which is of course complicated 
by a /foo/kde/x.y/share directory structure.  So most probably your 
suggestion is the best till now (and also one of the alternatives which was 
discussed for KDE 4).  A directory /usr/bin/kde/x.y feels weird on the 
first glance, but why not?

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Monday 20 September 2004 19:22, Carsten Lohrke wrote:
> I don't think that it should go in /opt, since the kde stuff is simply not
> more or less optional as everythin else. I wonder if it would be better to
> have /usr/lib/kde/x.y, /usr/share/kde/x.y,... directories!?
I've never seen the point of it. The kde directories include things under 
share/, like various docs, that make absolutely no sense somewhere 
under /usr/lib. And FHS forbids putting them there at least as much as it 
forbids creating a /usr/kde. I think that if we have to move, 
a /usr/packages/{kde,qt}/<version> pattern is best. ('patterns' apparently 
being replaced by a four-letter name - could someone enlighten me why that 
would be necessary?)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On Monday 20 September 2004 19:36, Malte S. Stretz wrote:
> That's actually a good point.  Theoretically its possible to share some
> parts of the system across several machines, which is of course complicated
> by a /foo/kde/x.y/share directory structure.  So most probably your
> suggestion is the best till now (and also one of the alternatives which was
> discussed for KDE 4).  A directory /usr/bin/kde/x.y feels weird on the
> first glance, but why not?

I don't understand this point. Could you please elaborate? Why is /usr/bin/kde 
better than either /usr/kde or /usr/packages/kde? Do you mean that kde should 
be split between /usr/{bin,lib,share,include,...}/kde/<version> dirs?

Specifying such separate dirs rather than a unified KDEDIR/KDEDIRS looks, at 
first sight, to be a major PITA. Maybe they'll improve support for this in 
kde4, but I don't relish the thought of doing it with 3.x. Unless there's a 
way already to specify such separated dirs via env variables a la KDEDIRS 
that I'm not aware of?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Malte S. Stretz]

On Monday 20 September 2004 18:44 CET Dan Armak wrote:
> On Monday 20 September 2004 19:36, Malte S. Stretz wrote:
> > That's actually a good point.  Theoretically its possible to share some
> > parts of the system across several machines, which is of course
> > complicated by a /foo/kde/x.y/share directory structure.  So most
> > probably your suggestion is the best till now (and also one of the
> > alternatives which was discussed for KDE 4).  A directory
> > /usr/bin/kde/x.y feels weird on the first glance, but why not?
>
> I don't understand this point. Could you please elaborate? Why is
> /usr/bin/kde better than either /usr/kde or /usr/packages/kde? Do you
> mean that kde should be split between
> /usr/{bin,lib,share,include,...}/kde/<version> dirs?

Yes.  The reason is that this would make KDE follow the rationale behind the 
FHS most:  Stuff in share can generally be shared (eg. NFS-mounted) across 
several machines, while lib continas platform-specific stuff and bin... you 
get the point.  This might happen rarely but it's the intention behind the 
split done in the FHS.

I don't know what you mean with docs which don't belong below lib in your 
other mail, was it a misunderstanding of Carsten's mail?

> Specifying such separate dirs rather than a unified KDEDIR/KDEDIRS looks,
> at first sight, to be a major PITA. Maybe they'll improve support for
> this in kde4, but I don't relish the thought of doing it with 3.x. Unless
> there's a way already to specify such separated dirs via env variables a
> la KDEDIRS that I'm not aware of?

I didn't say that this is already possible without much headache, just that 
it's maybe the best/cleanest solution for some distant future.

But actually, even currently I don't see a problem with that; the configure 
line would become rather long ('./configure --bindir=/usr/bin/kde/3.3 
--datadir=/usr/share/kde/3.3 ...') but at least there it would work.  And 
those dirs are available via eg. 'kde-config --path data' later on.

But I don't know how many stuff inside KDE or how many third-party tools 
depend on a "flat" $KDEDIR available via the environment variable(s) so 
this might indeed be stuff for KDE 4.

OTOH is it not like the current approach with /usr/kde eats your children or 
burns your box.  It's just not nice and FHS compliant and stuff but has 
been there for quite some time now and could stay as it is for another year 
or so until KDE 4 is released.  IMHO.

Btw, all this discussion was about KDE, I wonder how GNOME handles this 
stuff.  Does it also use /usr/gnome/x.y or so something else?

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

On Monday 20 September 2004 18:37, Dan Armak wrote:
> The kde directories include things under
> share/, like various docs, that make absolutely no sense somewhere
> under /usr/lib. 
Exactly this does not conform to the FHS iirc. 

# The following directories, or symbolic links to directories, must be
# in /usr/share, if the corresponding subsystem is installed:
#dict, doc, games, info, locale, nls, sgml, terminfo, database, tmac, xml,
#zoneinfo
#It is recommended that application-specific, architecture-independent
#directories be placed here.
http://www.pathname.com/fhs/pub/fhs-2.3.html

Which means e.g. kde's docs should go in /usr/share/doc/kde. Since we want to 
allow multiple kde versions, it would need to be 
either /usr/share/doc/kde/X.Y or /usr/share/doc/kdeX.Y. We do the latter for 
most ebuilds, since it is - in case of docs at least - policy to install them 
in ${D}/usr/share/docs/${PF}

> I think that if we have to move,
> a /usr/packages/{kde,qt}/<version> pattern is best. ('patterns' apparently
> being replaced by a four-letter name - could someone enlighten me why that
> would be necessary?)

/usr/packages/whatever is as FHS "conform" as /usr/kde.


From my point of view the kde location is not a big and if we want to change 
something, let's do it with qt/kde 4.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

On Monday 20 September 2004 20:19, Malte S. Stretz wrote:
> Yes.  The reason is that this would make KDE follow the rationale behind
> the FHS most:  Stuff in share can generally be shared (eg. NFS-mounted)
> across several machines, while lib continas platform-specific stuff and
> bin... you get the point.  This might happen rarely but it's the intention
> behind the split done in the FHS.
I see.

>
> I don't know what you mean with docs which don't belong below lib in your
> other mail, was it a misunderstanding of Carsten's mail?
My point was that since lib is meant for, well, libraries (and occasional 
binaries), it'd be inappropriate to put things like docs under it. Just 
inelegant, and people wouldn't expect it. Especially in view of the 
filesystem sharing scenario you outlined.

>
> > Specifying such separate dirs rather than a unified KDEDIR/KDEDIRS looks,
> > at first sight, to be a major PITA. Maybe they'll improve support for
> > this in kde4, but I don't relish the thought of doing it with 3.x. Unless
> > there's a way already to specify such separated dirs via env variables a
> > la KDEDIRS that I'm not aware of?
>
> I didn't say that this is already possible without much headache, just that
> it's maybe the best/cleanest solution for some distant future.
Definitely - if KDE makes it as easy as KDEDIRS, I'd vote for such a solution 
too in the longterm.

>
> But actually, even currently I don't see a problem with that; the configure
> line would become rather long ('./configure --bindir=/usr/bin/kde/3.3
> --datadir=/usr/share/kde/3.3 ...') but at least there it would work.  And
> those dirs are available via eg. 'kde-config --path data' later on.
>
> But I don't know how many stuff inside KDE or how many third-party tools
> depend on a "flat" $KDEDIR available via the environment variable(s) so
> this might indeed be stuff for KDE 4.
Seems like it to me, too.

>
> OTOH is it not like the current approach with /usr/kde eats your children
> or burns your box.  It's just not nice and FHS compliant and stuff but has
> been there for quite some time now and could stay as it is for another year
> or so until KDE 4 is released.  IMHO.
Agreed.

> Btw, all this discussion was about KDE, I wonder how GNOME handles this
> stuff.  Does it also use /usr/gnome/x.y or so something else?
No idea. I seem to remember gnome 1.4 and 2.0 coexisted back in the day, but 
don't remember how... Any gnome devs reading this thread? ;-)

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Monday 20 September 2004 18:36, Malte S. Stretz wrote:
> So most probably your 
> suggestion is the best till now (and also one of the alternatives which was
> discussed for KDE 4).  A directory /usr/bin/kde/x.y feels weird on the
> first glance, but why not?

Um, this wasn't meant to be a suggestion. My suggestion is to let it be as it 
is now, since a) it's not that important imho (me wonders about the size of 
this thread) and b) the above idea would probably cause trouble with a lot of 
hardcoded subdir's in Makefiles.

To those mentioning /usr/X11R6/ as an example. I think I read that the xorg 
guys planned to move away from this location and follow the FHS?!


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Monday 20 September 2004 17:40, Dan Armak wrote:
> On Monday 20 September 2004 11:48, Paul de Vrieze wrote:
> > ps. The other "solution" could be to do it like the eclipse ebuild does
> > and install in /usr/lib/eclipse or /usr/lib/kde/3.3, although I even like
> > it less. I think that our solution is best. To be FHS compliant (better,
> > to sidestep the FHS) we could make a new subdir to /usr where we put
> > these packages. This does not violate the FHS as no package is directly
> > under /usr and we still follow our own guidelines, and provide a clean
> > solution.
>
> Since the issue's been raised, I've nothing against this proposal. We want
> to counter the possible future problem of other packages following kde's
> lead and supporting multiple versions in separate directories, because many
> directories under /usr really is messy.
>
>  E.g., create a /usr/packages and put qt, kde and anything else there
> (/usr/packages/kde/3.2; ...). Who wants to take this proposal to the FHS
> people? :-)

I'll propose it to them in the case that there are more people that support 
this.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2086 bytes --]

On Monday 20 September 2004 19:35, Carsten Lohrke wrote:
> On Monday 20 September 2004 18:37, Dan Armak wrote:
> > The kde directories include things under
> > share/, like various docs, that make absolutely no sense somewhere
> > under /usr/lib.
>
> Exactly this does not conform to the FHS iirc.
>
> # The following directories, or symbolic links to directories, must be
> # in /usr/share, if the corresponding subsystem is installed:
> #dict, doc, games, info, locale, nls, sgml, terminfo, database, tmac, xml,
> #zoneinfo
> #It is recommended that application-specific, architecture-independent
> #directories be placed here.
> http://www.pathname.com/fhs/pub/fhs-2.3.html
>
> Which means e.g. kde's docs should go in /usr/share/doc/kde. Since we want
> to allow multiple kde versions, it would need to be
> either /usr/share/doc/kde/X.Y or /usr/share/doc/kdeX.Y. We do the latter
> for most ebuilds, since it is - in case of docs at least - policy to
> install them in ${D}/usr/share/docs/${PF}

No, it sais that those dirs should exist. Not that all docs should go there. 
In any case following that kind of policy would be pain in the ass for many 
packages that have different opinions.

>
> > I think that if we have to move,
> > a /usr/packages/{kde,qt}/<version> pattern is best. ('patterns'
> > apparently being replaced by a four-letter name - could someone enlighten
> > me why that would be necessary?)
>
> /usr/packages/whatever is as FHS "conform" as /usr/kde.

Probably more as it is not indirect, the FHS does not say anywhere that more 
dirs are not allowed they just specify the minimal set. It is perfectly legal 
to make aditions that do not violate the rules in the FHS. The /usr/packages 
idea does not violate this idea.

> From my point of view the kde location is not a big and if we want to
> change something, let's do it with qt/kde 4.

I don't mind keeping things this way, but people seem to want it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On Monday 20 September 2004 20:52, Paul de Vrieze wrote:
> No, it sais that those dirs should exist. Not that all docs should go
> there. In any case following that kind of policy would be pain in the ass
> for many packages that have different opinions.

Imho it is a better to follow a standard as strict as possible. The next one 
sees it a bit more lax and in the end you can forget the standard.

> > /usr/packages/whatever is as FHS "conform" as /usr/kde.
>
> Probably more as it is not indirect, the FHS does not say anywhere that
> more dirs are not allowed they just specify the minimal set.

#Chapter 4. The /usr Hierarchy

#Purpose

#/usr is the second major section of the filesystem. /usr is shareable, 
#read-only data. That means that /usr should be shareable between various 
#FHS-compliant hosts and must not be written to. Any information that is 
#host-specific or varies with time is stored elsewhere.

#Large software packages must not use a direct subdirectory under the /usr
#hierarchy

O.k., that doesn't forbid to add another directory and to use this one as a 
new base, but it still doesn't make sense to me. I see this formulation more 
as a gap in the standard. Either unintended or as a backwards compatibility 
thing to get everyone into the boat.

> > From my point of view the kde location is not a big and if we want to
> > change something, let's do it with qt/kde 4.
>
> I don't mind keeping things this way, but people seem to want it.

But they don't have to deal with the implications. Also users with a larger 
install base may have their backup scripts and so on, so such a decision 
should not be made for kde 3.x.


Carsten.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Malte S. Stretz]

On Monday 20 September 2004 20:30 CET Paul de Vrieze wrote:
> On Monday 20 September 2004 17:40, Dan Armak wrote:
> > On Monday 20 September 2004 11:48, Paul de Vrieze wrote:
> > > ps. The other "solution" could be to do it like the eclipse ebuild
> > > does and install in /usr/lib/eclipse or /usr/lib/kde/3.3, although I
> > > even like it less. I think that our solution is best. To be FHS
> > > compliant (better, to sidestep the FHS) we could make a new subdir to
> > > /usr where we put these packages. This does not violate the FHS as no
> > > package is directly under /usr and we still follow our own
> > > guidelines, and provide a clean solution.
> >
> > Since the issue's been raised, I've nothing against this proposal. We
> > want to counter the possible future problem of other packages following
> > kde's lead and supporting multiple versions in separate directories,
> > because many directories under /usr really is messy.
> >
> >  E.g., create a /usr/packages and put qt, kde and anything else there
> > (/usr/packages/kde/3.2; ...). Who wants to take this proposal to the
> > FHS people? :-)
>
> I'll propose it to them in the case that there are more people that
> support this.

To me the Carsten's proposal feels better.  Ie. split big "packages" 
into /usr/{bin,lib,share,doc,man}/<package>/<version>.  This if course 
could be written down in the FHS so those big packages make it possible to 
be split up in such a way :)

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[Malte S. Stretz]

On Monday 20 September 2004 17:56 CET Armando Di Cianno wrote:
> Just to be ontologically aligned with those that created the NeXTStep
> hierarchy, OS X (NeXTStep/OpenStep's logical descendants [alongside
> GNUstep]) has it's own UNIX-y/FHS-y hierarchy, from the BSD tools,
> _and_ a NeXT-y hierarchy.

Seems like GNUstep is a complicated one.  I have no idea how it looks like, 
but to mee it sounds like a whole different subsystem on top of the Linux 
base?  (Probably somehow like the Kolab server which too wants to create 
its own "root" somewhere, the default being /kolab).  I must admit that I 
have no idea how that fits in (if it can't be split up into something 
FHS-like).  But something like this sounds like a candidate for /opt to me.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?

[foser]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

On Mon, 2004-09-20 at 20:36 +0300, Dan Armak wrote:
> > Btw, all this discussion was about KDE, I wonder how GNOME handles this
> > stuff.  Does it also use /usr/gnome/x.y or so something else?
> No idea. I seem to remember gnome 1.4 and 2.0 coexisted back in the day, but 
> don't remember how... Any gnome devs reading this thread? ;-)

GNOME 2 versions all.  it's installed dirs &
libs : /usr/lib/libgnomeui-2.0.so, /usr/include/libgnome-2.0/, etc.
GNOME 1 didn't version at all so that didn't get in the way either.

We do not support having several versions in the same SLOT (literal
meaning) coexist like KDE does atm. eg. people can't have gnome 2.2 &
2.6 co-existing on a default install, but in my opinion there is no good
reason to support that.

- foser


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Joel Konkle-Parker]

Joshua J. Berry wrote:
> No, it's not special, but I think most people probably won't want a PATH
> variable that's 10,000 directories long.

Note that this is also a usability issue. I recently helped a friend set 
up Gentoo + KDE (first Linux experience), and the default PATH did not 
include the /usr/kde/x.x/bin dir, so he couldn't open KDE progs from the 
command line.

This may be an easy bug or configuration error in /etc/env.d, but the 
issue remains that it is easier for all the programs to be located in 
/usr/bin.


-- 
Joel Konkle-Parker
Webmaster  [Ballsome.com]

E-mail     [jjk3@msstate.edu]


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Joel Konkle-Parker]

Ciaran McCreesh wrote:
> On Mon, 20 Sep 2004 00:03:59 +0000 Luke-Jr <luke-jr@utopios.org> wrote:
> | Exactly. For a *system administrator* to *temporarily* mount a
> | filesystem in. This means 'mount some-temp-filesystem /mnt'
> | temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0
> | /mnt/floppy; etc' perminantly.-- 
> 
> Why have a specific toplevel for that? No need, just use cwd or $HOME.
> Surely you don't think the FHS is thaaaaat silly? By 'temporary' they've
> gotta mean 'not always mounted'. Anything else is madness.
> 

http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT

/media : Mount point for removeable media
Purpose

This directory contains subdirectories which are used as mount points 
for removeable media such as floppy disks, cdroms and zip disks.

Tip	Rationale
  	

Historically there have been a number of other different places used to 
mount removeable media such as /cdrom, /mnt or /mnt/cdrom. Placing the 
mount points for all removeable media directly in the root directory 
would potentially result in a large number of extra directories in /. 
Although the use of subdirectories in /mnt as a mount point has recently 
been common, it conflicts with a much older tradition of using /mnt 
directly as a temporary mount point.


-- 
Joel Konkle-Parker
Webmaster  [Ballsome.com]

E-mail     [jjk3@msstate.edu]


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Tuesday 21 September 2004 06:58, Joel Konkle-Parker wrote:
> Joshua J. Berry wrote:
> > No, it's not special, but I think most people probably won't want a PATH
> > variable that's 10,000 directories long.
>
> Note that this is also a usability issue. I recently helped a friend set
> up Gentoo + KDE (first Linux experience), and the default PATH did not
> include the /usr/kde/x.x/bin dir, so he couldn't open KDE progs from the
> command line.
>
> This may be an easy bug or configuration error in /etc/env.d, but the
> issue remains that it is easier for all the programs to be located in
> /usr/bin.

The contents of /etc/env.d/47kdepaths-3.3.0 on my computer (automatically 
installed):
PATH=/usr/kde/3.3/bin
ROOTPATH=/usr/kde/3.3/sbin:/usr/kde/3.3/bin
LDPATH=/usr/kde/3.3/lib
CONFIG_PROTECT=/usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown

Of course this only works after a reboot or env-update and relogin.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Duncan]

Carsten Lohrke posted <200409202117.34236.carlo@gentoo.org>, excerpted
below,  on Mon, 20 Sep 2004 21:17:26 +0200:

> #Chapter 4. The /usr Hierarchy
> 
> #Purpose
> 
> #/usr is the second major section of the filesystem. /usr is shareable, 
> #read-only data. That means that /usr should be shareable between various 
> #FHS-compliant hosts and must not be written to. Any information that is 
> #host-specific or varies with time is stored elsewhere.
> 
> #Large software packages must not use a direct subdirectory under the /usr
> #hierarchy
> 
> O.k., that doesn't forbid to add another directory and to use this one as a 
> new base, but it still doesn't make sense to me. I see this formulation more 
> as a gap in the standard. Either unintended or as a backwards compatibility 
> thing to get everyone into the boat.

OK, since nobody else has brought this up, I must be reading something
wrong, but I don't see what the problem is here.  (I also repeat myself a
bit below.  However, it's so obvious here, I find it difficult to believe
that someone else hasn't seen it either.  Yet the fact remains I
haven't seen it mentioned yet, in what has become a rather long thread.
That must mean it's non-obvious, despite what it seems here, so excuse a
bit of belaboring of the point in my attempt to make it equally obvious
to others! <g>)

As I see it, we are NOT putting "large packages" directly under /usr,
because the "large packages" in question are versioned (slotted per
individual directory) and under /kde.  As I read the spec, /usr/kde is
already a level of indirection, because our packages are (perfectly
logically, it seems to me) laid out beneath /usr/kde and not directly in
/usr.

IOW, the way I read it, /usr/kde-3.3 would be a violation, but
/usr/kde/3.3 isn't, because it's already a level of indirection.  Just
because we've chosen to only put KDE related packages at that specific
case of the indirection level means nothing.  The packages are STILL not
directly under /usr.

Now, I WOULD have an issue with /usr/kde-3.3, and /usr/kde-3.2, and
/usr/kde-4.0, etc (and noting that with other distribs there'd likely be
only a single version-slot under /usr/kde). That's just a ridiculous
proliferation directly under /usr and I'm sure everyone would agree.
However, as has already come up, given the large (both in size and in
dependencies) tree that  is KDE, I see nothing at all wrong with putting
that dir itself (not the packages or slots in it) directly under /usr, nor
can I see how it conflicts with the quoted rules above.

Again, for those distribs without multiple KDE slots, a single /usr/kde
would indeed be a violation, as it's just a single (meta-)package. 
However, the fact that we've chosen to group a very large package set that
under our (meta-)distribution could reasonably be several multiples of the
size of /most/ distribution's kde, under a /usr direct subdir with each
instance of our multiples below that, doesn't seem to me to be in conflict
with the FHS at all.  Again, as others have pointed out in other contexts,
there's nothing wrong with adding /more/ dirs.  We just have to have the
basics and observe the rules about what goes in them.

Putting it another way, we've already proposed /usr/packages.  Now, if we
got a whole bunch of packages, there'd be nothing wrong with splitting
that into say /usr/pkg-a-m, and /usr/pkg-n-z, right?  OK, what if there
were more k- packages than all the others combined?  There wouldn't be a
problem with /usr/pkg-but-k and /usr/pkg-k, right?

We've just done gone the logical next step.  Because KDE is multi-slotted,
and with KDE as big as it is already and the slotting essentially
multiplying that X times, we've just created what is essentially
/usr/pkg-kde, only without the pkg- part.  I still contend that we aren't
putting our packages directly under /usr, as each package is in fact in a
slot in kde in /usr.  Where's the FHS violation?  I can't see it?

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Duncan]

Duncan posted <pan.2004.09.21.10.47.48.152334@cox.net>, excerpted below, 
on Tue, 21 Sep 2004 03:47:49 -0700:

> OK, since nobody else has brought this up, I must be reading something
> wrong, but I don't see what the problem is here.

OK, so since I wrote that, I now see that Paul mentioned it.  However, no
replies yet.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1452 bytes --]

On Tuesday 21 September 2004 12:47, Duncan wrote:

> IOW, the way I read it, /usr/kde-3.3 would be a violation, but
> /usr/kde/3.3 isn't, because it's already a level of indirection.
[..]
>  Where's the FHS violation?  I can't see it?

Yes Duncan, you're right about the KDE path. Didn't had in mind that kde/ 
itself is a level of indirection and x.y/ the real package directory. That's 
o.k., if you read the FHS in a way that other than the mentioned directories 
in /usr are allowed. If you see it from a strict standardization perspective, 
this shouldn't be the case. If every distro adds directories life doesn't get 
easier for people using more than one distro or having to switch to another. 
Reliable paths ease writing and maintaining of all sorts of scripts, too. 
This is my very reason to let kde were it is (for now), btw.. You undermine a 
standard, if you expoit every gap you can find in it.

>However, as has already come up, given the large (both in size and in
>dependencies) tree that  is KDE, I see nothing at all wrong with putting
>that dir itself (not the packages or slots in it) directly under /usr, nor
>can I see how it conflicts with the quoted rules above.

This is the amusing point. I don't really get the argument to 
move /usr/kde(/x.y) elsewhere because of its size. The way it is now is the 
most simple way to put the whole kde stuff on a extra partition, if you like 
to.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Helmar Wieland]

Joel Konkle-Parker schrieb  am 21.09.2004 07:10:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT
> 
> /media : Mount point for removeable media
> Purpose
> 
> This directory contains subdirectories which are used as mount points 
> for removeable media such as floppy disks, cdroms and zip disks.

I entered this into bugzilla quiet some time ago:
http://bugs.gentoo.org/show_bug.cgi?id=41519

It became a WONTFIX, since the majority of gentoo devs (which replied to
this bug) didn't want to change the behaviour they were familiar with :-(

So at least we've got something to do after each baselayout upgrade...


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[John Croisant]

Dan Armak <danarmak <at> gentoo.org> writes:
>
> /usr/qt,kde was my decision at the time. I didn't see any obvious better 
> FHS-mandated place to put them in. If there's a better place, I'd at least 
> like to hear about it.
 
I'm a fan of tearing KDE/QT apart and scattering the pieces into their proper,
FHS-friendly places. That is, /usr/kde/share might become /usr/share/kde-X.Y,
and so on. /usr/{kde,qt}/ would be phased out (perhaps keep a directory full of
symlinks to the new places while everything settles). Whether or not this is
feasible, I can't say -- but it sure would be fun for whoever writes the ebuild!

To let multiple versions co-exist, you could use version appending for
directories/libraries (/usr/lib/kde-X.Y) (this is what gnome-2 uses, as foser
pointed out, http://article.gmane.org/gmane.linux.gentoo.devel/21414 ). I don't
see anything in the FHS this goes against (in word or spirit, as I read it), and
a few packages in portage already use this style (not just in /usr/share, but in
/usr/lib, /usr/bin, etc). Taking a peek in /usr/lib, I see Abiword-2.0, gtk-2.0,
the gnome-related libraries, and python having directories using this versioning
system (although python doesn't use the dash). Plus, it seems (to me, at least!)
to make sense: the shared directories are versioned, the library files directly
in /usr/lib are versioned (libfoo.so[.x[.y.z]]), so why not the library
directories in /usr/lib?

The FHS defines the bare minimum (and a few optional) presence of directories,
but beyond that some decision should be made, ideally between distros (and maybe
even between *nixes), as to what hierarchy/naming conventions should be used for
subdirectories.

Hopefully, the new major versions of KDE and QT will make it clearer where they
should go (perhaps by separating the files in a FHS-friendly way). I don't think
that leaving /usr/{kde,qt} in place for the current versions, and "starting
fresh" with the new versions would work, because you'd have to keep the current
versions around anyway (or start up this discussion again) for applications that
don't get updated to the new KDE or QT versions.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]

On Tuesday 28 September 2004 04:51, John Croisant wrote:
> I'm a fan of tearing KDE/QT apart and scattering the pieces into their
> proper, FHS-friendly places. That is, /usr/kde/share might become
> /usr/share/kde-X.Y, and so on. /usr/{kde,qt}/ would be phased out
> (perhaps keep a directory full of symlinks to the new places while
> everything settles). Whether or not this is feasible, I can't say --
> but it sure would be fun for whoever writes the ebuild!

Too much fun. Have you ever tried to maintain patches on a package with 
new versions comming out all the time?

>
> To let multiple versions co-exist, you could use version appending for
> directories/libraries (/usr/lib/kde-X.Y) (this is what gnome-2 uses, as
> foser pointed out,
> http://article.gmane.org/gmane.linux.gentoo.devel/21414 ). I don't see
> anything in the FHS this goes against (in word or spirit, as I read
> it), and a few packages in portage already use this style (not just in
> /usr/share, but in /usr/lib, /usr/bin, etc). Taking a peek in /usr/lib,
> I see Abiword-2.0, gtk-2.0, the gnome-related libraries, and python
> having directories using this versioning system (although python
> doesn't use the dash). Plus, it seems (to me, at least!) to make sense:
> the shared directories are versioned, the library files directly in
> /usr/lib are versioned (libfoo.so[.x[.y.z]]), so why not the library
> directories in /usr/lib?

Do you realize that this would amount to serious patches on kde. KDE 
expects KDEDIR(S) to work the way it does currently. I know it is not 
ideal, but neither is the FHS.

>
> The FHS defines the bare minimum (and a few optional) presence of
> directories, but beyond that some decision should be made, ideally
> between distros (and maybe even between *nixes), as to what
> hierarchy/naming conventions should be used for subdirectories.
>
> Hopefully, the new major versions of KDE and QT will make it clearer
> where they should go (perhaps by separating the files in a FHS-friendly
> way). I don't think that leaving /usr/{kde,qt} in place for the current
> versions, and "starting fresh" with the new versions would work,
> because you'd have to keep the current versions around anyway (or start
> up this discussion again) for applications that don't get updated to
> the new KDE or QT versions.

You might petition to the qt/kde people, I don't give you much chance, but 
the main reason for the current setup is based on the kde/qt setup.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Peter Ruskin]

On Tuesday 28 September 2004 09:19, Paul de Vrieze wrote:
> Do you realize that this would amount to serious patches on kde. KDE
> expects KDEDIR(S) to work the way it does currently. I know it is not
> ideal, but neither is the FHS.

Well I think it *is* ideal the way we have it - that was one of the many 
things that attracted me to Gentoo in the first place.  It's the most 
sensible way I've come across for organizing KDE/Qt and we should not 
even consider abandoning it.

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.0.50-r11. kernel-2.6.8-gentoo-r4.
i686 AMD Athlon(tm) XP 3200+.  gcc(GCC): 3.4.2.
KDE: 3.3.0.    Qt: 3.3.3.
========================================================================

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Tuesday 28 September 2004 11:24, Peter Ruskin wrote:
> On Tuesday 28 September 2004 09:19, Paul de Vrieze wrote:
> > Do you realize that this would amount to serious patches on kde. KDE
> > expects KDEDIR(S) to work the way it does currently. I know it is not
> > ideal, but neither is the FHS.
>
> Well I think it *is* ideal the way we have it - that was one of the
> many things that attracted me to Gentoo in the first place.  It's the
> most sensible way I've come across for organizing KDE/Qt and we should
> not even consider abandoning it.

Ideal to me would be a way that has the same power as the current way, but 
without getting on the edge of the FHS (so also pleasing the people who 
value that greatly). I agree however that this is probably the best way 
to do it as long as the FHS does not really offer support for our way of 
operation.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[John Croisant]

On Tue, 28 Sep 2004 10:19:29 +0200, Paul de Vrieze <pauldv@gentoo.org> wrote:
> 
> Do you realize that this would amount to serious patches on kde. KDE
> expects KDEDIR(S) to work the way it does currently. I know it is not
> ideal, but neither is the FHS.

I don't pretend to be an expert on how KDE works, which is why I ask:
why couldn't you add the scattered directories to KDEDIRS? The
documentation I have read suggests that KDE will search all
directories in KDEDIRS for the files it needs. Am I missing something?

I assume that there is some sort of conflict such that it wouldn't
work for KDE to have all versions in its path. Is it possible to tell
an application which KDEDIRS to use (again assuming that KDEDIRS would
have to be different for different versions of KDE), without patching
the application or KDE? Could a script be written that would define
KDEDIRS for an application call? Is there a way to automatically
detect whether an application uses one version of KDE or another?
Could some function be easily added to all KDE-related ebuilds, to
create a wrapper script for the applications?

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

On Tuesday 28 September 2004 22:32, John Croisant wrote:
> I don't pretend to be an expert on how KDE works, which is why I ask:
> why couldn't you add the scattered directories to KDEDIRS? The
> documentation I have read suggests that KDE will search all
> directories in KDEDIRS for the files it needs. Am I missing something?
>
> I assume that there is some sort of conflict such that it wouldn't
> work for KDE to have all versions in its path. Is it possible to tell
> an application which KDEDIRS to use (again assuming that KDEDIRS would
> have to be different for different versions of KDE), without patching
> the application or KDE? Could a script be written that would define
> KDEDIRS for an application call? Is there a way to automatically
> detect whether an application uses one version of KDE or another?
> Could some function be easily added to all KDE-related ebuilds, to
> create a wrapper script for the applications?

The elements of the KDEDIRS directory is supposed to be a root directory 
(under which the bin,share,lib,include etc. directories should be 
located). Scattering is not an option. To detect which kde version is 
used one could use ldd and check the libkdecore version.

Paul
>
> --
> gentoo-dev@gentoo.org mailing list

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]