1 |
>> I see this as an advantage above e.g. Fink, with its own namespace. The |
2 |
>> namespace variant implies that I have to fudge around with PATH |
3 |
>> variables |
4 |
>> and other CLI stuff, in order to get the apps working. I still have no |
5 |
>> real MacOSX integration, with App folder and GUI starter elements (which |
6 |
>> would be my biggest feature request) |
7 |
> |
8 |
> I see not trashing the existing system software as far more important |
9 |
> than the minor configuration of your path. This is Gentoo! What "App |
10 |
> folder" are you expecting? KDE menus, Gnome menus, etc. are basically |
11 |
> fancy widgets that execute CLI commands when you click on them. |
12 |
|
13 |
Sorry, but this attitude firmly belong into the "a GUI is just a frontend |
14 |
to the CLI" camp, where I don't really subscribe too. A CLI has its place, |
15 |
but a GUI does so, too, and both are not dependent upon. |
16 |
KDE / GNOME .desktop entries doesn't really compare to Apple's app |
17 |
folders, because .desktop entries are really just start scripts. An app |
18 |
folder contains starting scripts and the related resources / libraries in |
19 |
an all in one package. The idea is that you can copy an app folder around |
20 |
in your local file system or to another file system (thing .dmg here), |
21 |
while the application still remains runnable. So you have to include any |
22 |
library, beside the Apple provided ones. |
23 |
|
24 |
> If you need something to click on for your own sanity, the logical thing |
25 |
> for you to do would be to create some scripts in /Applications that |
26 |
> call the X apps you use when you click on them, assuming you got the X |
27 |
> apps installed in the first place. I wouldn't be surprised if someone |
28 |
> came up with a fink-commander-like project for OS X (to install and |
29 |
> run stuff) if the prefixed-installs-hurdle ever gets passed. |
30 |
|
31 |
>From what I see, fink-commander is a frontend to fink, i.e. to the |
32 |
packages, not to the actual applications. Last time I checked, a gentoo or |
33 |
fink package has no concept about which are the actual executables. |
34 |
|
35 |
> |
36 |
>> From what I see as a user, the Gentoo packages divide into 4 categories |
37 |
>> |
38 |
>> 1) packages which integrate nicely into the system (no dependencies, or |
39 |
>> dependencies which are properly provided by MacOS) |
40 |
> |
41 |
> No collisions and no dependencies? No reason to wait for gentoo-osx then. |
42 |
|
43 |
No complicated dependencies. So this is the easiest part, where I still |
44 |
like to have Gentoo's safety net which keeps knowledge about what files |
45 |
belong to which package. This allows for clean uninstall, at least what |
46 |
concerns removing files. I am not quite sure about Fink style install and |
47 |
uninstall scripts. |
48 |
|
49 |
> |
50 |
>> 2) packages which clash with MacOS provided packages, things like python |
51 |
>> or automake spring to mind |
52 |
> |
53 |
> And bash, ls, grep, emacs, vi, vim, gcc, perl, python, tcl/tk, apache, |
54 |
> etc. etc. etc. |
55 |
|
56 |
python and automake are the cases which really annoy me, but naturally you |
57 |
are correct about the other packages, too. If possible I would like to use |
58 |
an Apple provided gcc, so this package is disputable. |
59 |
|
60 |
> I would guess this is a _lot_ of packages, including most of the stuff |
61 |
> that just having a gentoo system depends on. |
62 |
> |
63 |
>> 3) packages which depend on 2) |
64 |
> |
65 |
> This wold be the rest of the packages. |
66 |
|
67 |
Yes and no. For me 3) are the packages, which I would like to emerge, but |
68 |
I cannot because of missing 2) packages. 4) are packages which are still |
69 |
considered unstable / problematic by the package maintainers, so that I |
70 |
don't want to toy around with, yet. |
71 |
|
72 |
>> The biggest problem is obiously the packages in 2) |
73 |
> |
74 |
> Which prefixed installs will solve. When portage fully supports |
75 |
> prefixed installs, then: |
76 |
> (1) A base system gets created by devs by whatever means (hopefully |
77 |
> the only step with mandatory dependencies on Apple tools) |
78 |
> (2) Regular users install the prefix-enabled base system into a prefix |
79 |
> (and add $PREFIX/bin, $PREFIX/sbin, etc. to .bashrc) |
80 |
> (3) 'emerge mypackage' uses the gentoo system in $PREFIX to build |
81 |
> 'mypackage' and install in into |
82 |
> $PREFIX/regular/gentoo/path/for/the/package |
83 |
> (4) USERS REJOICE! |
84 |
> (5) At this point, I'm sure someone will start a 'fink-commander'-like |
85 |
> project for people who aren't comfortable with the command-line |
86 |
> |
87 |
|
88 |
Maybe I am just not in possession of all the facts, so I will stop |
89 |
expressing an opinion about this as long as there are no visible results. |
90 |
|
91 |
> Manually "install" packages whose dependencies won't install? I think |
92 |
> you have missed the concept that the dependencies are necessary to |
93 |
> both compile and run the package. |
94 |
> |
95 |
|
96 |
No. manually installing the packages which are needed to emerge the actual |
97 |
wanted packages. The latter are still emerged via Gentoo. |
98 |
|
99 |
Regards |
100 |
Dirk |
101 |
|
102 |
|
103 |
-- |
104 |
gentoo-osx@g.o mailing list |