| 1 |
On Sun, Sep 19, 2004 at 11:37:55PM +0300, Dan Armak wrote: |
| 2 |
> On Sunday 19 September 2004 23:26, Joshua J. Berry wrote: |
| 3 |
> |
| 4 |
> > and (b) they are both heavily-bloated, |
| 5 |
> Bloated in what respect? Size, speed? And what does it have to do with where |
| 6 |
> we install them to? |
| 7 |
|
| 8 |
Size (specifically, number of files). For example: |
| 9 |
|
| 10 |
condor@alnath /usr/kde/3.3/bin> ls |wc -l |
| 11 |
368 |
| 12 |
condor@alnath /usr/kde/3.3/lib> ls |wc -l |
| 13 |
733 |
| 14 |
|
| 15 |
That could pollute the /usr hierarchy quite a bit, which is why I think moving |
| 16 |
it to straight /usr is a bad idea. |
| 17 |
|
| 18 |
> > and you probably don't want to |
| 19 |
> > pollute /usr... |
| 20 |
> It's true that I don't want to, only I don't see a better solution. |
| 21 |
> |
| 22 |
> If there's a general consensus on moving to /opt I can live with that, because |
| 23 |
> it doesn't affect the ebuilds/eclasses/results one bit. It's just that it's |
| 24 |
> entirely inconsistent with the way we're using /opt right now. |
| 25 |
|
| 26 |
Perhaps we need to reevaluate how we're using /opt. |
| 27 |
|
| 28 |
I'm fine with the current /usr/kde/<version> scheme, but the FHS says that's a |
| 29 |
no-no. But, they say /opt/<package> is perfectly OK for "add-on" software. |
| 30 |
|
| 31 |
From an FHS perspective, the only question is whether or not KDE constitutes |
| 32 |
"add-on" software. We could have a flamewar on that question for the next 10 |
| 33 |
years and not get anywhere. ;) |
| 34 |
|
| 35 |
> And what if, in a year from now, twenty other projects will decide it's good |
| 36 |
> for the users to allow many versions to be installed side by side? Will we |
| 37 |
> move everything to /opt? My point here is that kde itself is not special in |
| 38 |
> any way (although qt arguably is, since you do want different qt2 and qt3 |
| 39 |
> programs side by side, but then the qt libraries could live together in /usr |
| 40 |
> with some effort). It's just that kde users asked for this functionality a |
| 41 |
> lot, so I added it. Apart from running two stable trees, kde developers use |
| 42 |
> this to run a stable tree and cvs HEAD. |
| 43 |
|
| 44 |
No, it's not special, but I think most people probably won't want a PATH |
| 45 |
variable that's 10,000 directories long. ;) The only thing that makes it |
| 46 |
"special" IMHO is how big it is. |
| 47 |
|
| 48 |
For smaller packages, it would probably just be easier to do something similar |
| 49 |
to what we do right now for GIMP and rename the binaries (you're only talking a |
| 50 |
few, not hundreds as would be the case with KDE). |
| 51 |
|
| 52 |
-- |
| 53 |
Joshua J. Berry |
| 54 |
|
| 55 |
"I haven't lost my mind -- it's backed up on tape somewhere." |
| 56 |
-- /usr/games/fortune |
Archives