| 1 |
Good to see you posting, Dirk! |
| 2 |
|
| 3 |
dirk.schoenberger@×××××××××.de wrote: |
| 4 |
>> The Portage take on this would be slightly different, as it will live |
| 5 |
>> in its own space, with its own set of GUI accessible .apps, |
| 6 |
>> Frameworks, etc. Can you elaborate on "I have to fudge around with |
| 7 |
>> PATH variables and other CLI stuff" |
| 8 |
> |
| 9 |
> In a more Fink inspired way, I think I would have to add at lease a |
| 10 |
> PATH=$PATH:/sw/bin resp. the settings for LD_LIBRARY_PATH (or whatever the |
| 11 |
> Mac equivalent is) |
| 12 |
|
| 13 |
Ok, but this is of a small concern since you can just add it to your |
| 14 |
.bashrc or .tcshrc or whichever .shellrc you use. Just like fink tells |
| 15 |
you to source one of their files, we could do the same. Such thing |
| 16 |
allows you to make it all accessible without needing lengthy workarounds. |
| 17 |
|
| 18 |
>> and "real MacOSX integration, with App folder and GUI starter elements" |
| 19 |
> please? |
| 20 |
> |
| 21 |
> With this I mean anything which enables me to e.g start X based |
| 22 |
> application via the Finder, instead of from a command line. App folder |
| 23 |
> would e.g allow me to create a "standalone" application which I can put on |
| 24 |
> another machine, without having to re-install the whole Gentoo system. I |
| 25 |
> know that this somehow circumvent the whole reason of Gentoo, namely the |
| 26 |
> automatic maintenance and update of components and their dependent |
| 27 |
> applications. |
| 28 |
|
| 29 |
This is a really cool thought. I quick first impression is that this |
| 30 |
should be possible, since on OSX the dylibs can be moved to another |
| 31 |
location, or even be in a relative location as in all the .app things. |
| 32 |
So perhaps it would indeed be possible to write a script that generates |
| 33 |
such app. Practical problems may arise, but I like the idea. |
| 34 |
|
| 35 |
>>> From what I see as a user, the Gentoo packages divide into 4 |
| 36 |
>>> categories |
| 37 |
>>> |
| 38 |
>>> 1) packages which integrate nicely into the system (no |
| 39 |
>>> dependencies, or |
| 40 |
>>> dependencies which are properly provided by MacOS) |
| 41 |
>> The problems with this have been outlined numerous times by both |
| 42 |
>> users and devs, but to quickly re-hash them: It makes system backups/ |
| 43 |
>> reinstalls a pain, the deps that are 'properly' provided by apple can |
| 44 |
>> and will change without notice, it requires manual mapping of faux- |
| 45 |
>> deps via the profiles, a software update or `diskutil |
| 46 |
>> repairPermissions /` can render your portage installed files useless, |
| 47 |
>> its what keeps the project a laughable novelty to most Darwin/OS X |
| 48 |
>> users and developers |
| 49 |
|
| 50 |
But... I do understand you, because I did like it too, when I tried |
| 51 |
Gentoo for OSX, that it installs in /usr/bin. However, now I know a bit |
| 52 |
more on the real implications of that choice and how fragile and |
| 53 |
polluting it is, I prefer to have a nice corner on my system which |
| 54 |
Portage doesn't have to share with anyone. |
| 55 |
|
| 56 |
> I am not so long a member of the list, so thanks for the short repetition. |
| 57 |
> Is it possible to define some kind of "safe subset" of Apple provided |
| 58 |
> packages, i.e something which is less likely to change frequently? |
| 59 |
|
| 60 |
I guess this answer would be no. Apple changes things quite often and |
| 61 |
doesn't care about backwards compatibility with devs so much as far as I |
| 62 |
can tell. It's their way to innovate and react quickly to the market. |
| 63 |
(Which is one of their core competencies.) So basically, I think the |
| 64 |
proper way to think is: "don't trust anything you didn't create |
| 65 |
yourself". Kito, correct me if I'm wrong here. |
| 66 |
|
| 67 |
>> A USE flag for what exactly? I'm not sure I understand you. |
| 68 |
> |
| 69 |
> Something like USE="install-local", which installs the package into |
| 70 |
> /usr/local instead of /usr. |
| 71 |
> In the default console settings this should override Apple provided |
| 72 |
> packages, without leading to collisions. |
| 73 |
|
| 74 |
An interesting thought, but why would a user have to do this him or |
| 75 |
herself? I'd immediately say that portage would have to do this |
| 76 |
automatically when necessary. Why bother a (Mac) user with it? Since |
| 77 |
this is a bit complicated, and asks more from Portage (flexible install |
| 78 |
location) the current approach is to diss the automatic part and just |
| 79 |
always install into an alternative location, since that won't ever |
| 80 |
collide with system installed stuff *and* is easier to do in Portage as |
| 81 |
far as I have understood the discussions on it. |
| 82 |
|
| 83 |
|
| 84 |
-- |
| 85 |
Fabian Groffen |
| 86 |
Gentoo for Mac OS X Project -- Interim Lead |
| 87 |
-- |
| 88 |
gentoo-osx@g.o mailing list |
Archives