| 1 |
> If you want to keep a "pure" Unix system hierarchy (which is my intention) |
| 2 |
> you should try to keep all elements on the place |
| 3 |
> where they are expected. This means no additional appendizes just because |
| 4 |
it |
| 5 |
> is technically opportune. |
| 6 |
|
| 7 |
> If I wanted a unclean file system, I could change to DarwinPorts or Fink |
| 8 |
;) |
| 9 |
|
| 10 |
Just to show what I mean: |
| 11 |
|
| 12 |
My idea is to implement a better MacOS GUI integration of Gentoo installed |
| 13 |
tools. |
| 14 |
This means real app folders which contain the actual GUI and which call the |
| 15 |
correct Unix executables. |
| 16 |
These packages could either directly packages in ebuilds, or they could be |
| 17 |
external packages which are dependent on the actuall application. |
| 18 |
I.e. something like |
| 19 |
|
| 20 |
depends on |
| 21 |
ghostscript-gui <----- ghostscript |
| 22 |
|
| 23 |
In a non-prefixed approach, I can be sure that there will exist an |
| 24 |
executable /usr/bin/gs, which I can call. |
| 25 |
What I am to do in a prefixed system? Hope that the users did not forget to |
| 26 |
call setenv-gentoo on bootup? |
| 27 |
Start a local shell which calls setenv-gentoo, which maybe itself be |
| 28 |
somewhere on |
| 29 |
/Volumes/usbdrive/.hidden/far_away/big/long/path/to/gentoo/bin/setenv-gentoo |
| 30 |
And do a exec "/bin/sh gs"? This sounds like a rather big security problem |
| 31 |
to me, because nothing stops any malware to change things like |
| 32 |
the path variable. |
| 33 |
|
| 34 |
Regards |
| 35 |
Dirk |
| 36 |
|
| 37 |
|
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-osx@g.o mailing list |
Archives