| 1 |
On Tuesday 28 September 2004 04:51, John Croisant wrote: |
| 2 |
> I'm a fan of tearing KDE/QT apart and scattering the pieces into their |
| 3 |
> proper, FHS-friendly places. That is, /usr/kde/share might become |
| 4 |
> /usr/share/kde-X.Y, and so on. /usr/{kde,qt}/ would be phased out |
| 5 |
> (perhaps keep a directory full of symlinks to the new places while |
| 6 |
> everything settles). Whether or not this is feasible, I can't say -- |
| 7 |
> but it sure would be fun for whoever writes the ebuild! |
| 8 |
|
| 9 |
Too much fun. Have you ever tried to maintain patches on a package with |
| 10 |
new versions comming out all the time? |
| 11 |
|
| 12 |
> |
| 13 |
> To let multiple versions co-exist, you could use version appending for |
| 14 |
> directories/libraries (/usr/lib/kde-X.Y) (this is what gnome-2 uses, as |
| 15 |
> foser pointed out, |
| 16 |
> http://article.gmane.org/gmane.linux.gentoo.devel/21414 ). I don't see |
| 17 |
> anything in the FHS this goes against (in word or spirit, as I read |
| 18 |
> it), and a few packages in portage already use this style (not just in |
| 19 |
> /usr/share, but in /usr/lib, /usr/bin, etc). Taking a peek in /usr/lib, |
| 20 |
> I see Abiword-2.0, gtk-2.0, the gnome-related libraries, and python |
| 21 |
> having directories using this versioning system (although python |
| 22 |
> doesn't use the dash). Plus, it seems (to me, at least!) to make sense: |
| 23 |
> the shared directories are versioned, the library files directly in |
| 24 |
> /usr/lib are versioned (libfoo.so[.x[.y.z]]), so why not the library |
| 25 |
> directories in /usr/lib? |
| 26 |
|
| 27 |
Do you realize that this would amount to serious patches on kde. KDE |
| 28 |
expects KDEDIR(S) to work the way it does currently. I know it is not |
| 29 |
ideal, but neither is the FHS. |
| 30 |
|
| 31 |
> |
| 32 |
> The FHS defines the bare minimum (and a few optional) presence of |
| 33 |
> directories, but beyond that some decision should be made, ideally |
| 34 |
> between distros (and maybe even between *nixes), as to what |
| 35 |
> hierarchy/naming conventions should be used for subdirectories. |
| 36 |
> |
| 37 |
> Hopefully, the new major versions of KDE and QT will make it clearer |
| 38 |
> where they should go (perhaps by separating the files in a FHS-friendly |
| 39 |
> way). I don't think that leaving /usr/{kde,qt} in place for the current |
| 40 |
> versions, and "starting fresh" with the new versions would work, |
| 41 |
> because you'd have to keep the current versions around anyway (or start |
| 42 |
> up this discussion again) for applications that don't get updated to |
| 43 |
> the new KDE or QT versions. |
| 44 |
|
| 45 |
You might petition to the qt/kde people, I don't give you much chance, but |
| 46 |
the main reason for the current setup is based on the kde/qt setup. |
| 47 |
|
| 48 |
Paul |
| 49 |
|
| 50 |
-- |
| 51 |
Paul de Vrieze |
| 52 |
Gentoo Developer |
| 53 |
Mail: pauldv@g.o |
| 54 |
Homepage: http://www.devrieze.net |
Archives