| 1 |
>> |
| 2 |
>> I see this as an advantage above e.g. Fink, with its own namespace. |
| 3 |
>> The |
| 4 |
>> namespace variant implies that I have to fudge around with PATH |
| 5 |
>> variables |
| 6 |
>> and other CLI stuff, in order to get the apps working. I still have no |
| 7 |
>> real MacOSX integration, with App folder and GUI starter elements |
| 8 |
>> (which |
| 9 |
>> would be my biggest feature request) |
| 10 |
> |
| 11 |
> The Portage take on this would be slightly different, as it will live |
| 12 |
> in its own space, with its own set of GUI accessible .apps, |
| 13 |
> Frameworks, etc. Can you elaborate on "I have to fudge around with |
| 14 |
> PATH variables and other CLI stuff" |
| 15 |
|
| 16 |
In a more Fink inspired way, I think I would have to add at lease a |
| 17 |
PATH=$PATH:/sw/bin resp. the settings for LD_LIBRARY_PATH (or whatever the |
| 18 |
Mac equivalent is) |
| 19 |
|
| 20 |
> and "real MacOSX integration, with App folder and GUI starter elements" |
| 21 |
please? |
| 22 |
|
| 23 |
With this I mean anything which enables me to e.g start X based |
| 24 |
application via the Finder, instead of from a command line. App folder |
| 25 |
would e.g allow me to create a "standalone" application which I can put on |
| 26 |
another machine, without having to re-install the whole Gentoo system. I |
| 27 |
know that this somehow circumvent the whole reason of Gentoo, namely the |
| 28 |
automatic maintenance and update of components and their dependent |
| 29 |
applications. |
| 30 |
|
| 31 |
>> |
| 32 |
>> From what I see as a user, the Gentoo packages divide into 4 |
| 33 |
>> categories |
| 34 |
>> |
| 35 |
>> 1) packages which integrate nicely into the system (no |
| 36 |
>> dependencies, or |
| 37 |
>> dependencies which are properly provided by MacOS) |
| 38 |
> |
| 39 |
> The problems with this have been outlined numerous times by both |
| 40 |
> users and devs, but to quickly re-hash them: It makes system backups/ |
| 41 |
> reinstalls a pain, the deps that are 'properly' provided by apple can |
| 42 |
> and will change without notice, it requires manual mapping of faux- |
| 43 |
> deps via the profiles, a software update or `diskutil |
| 44 |
> repairPermissions /` can render your portage installed files useless, |
| 45 |
> its what keeps the project a laughable novelty to most Darwin/OS X |
| 46 |
> users and developers |
| 47 |
|
| 48 |
I am not so long a member of the list, so thanks for the short repetition. |
| 49 |
Is it possible to define some kind of "safe subset" of Apple provided |
| 50 |
packages, i.e something which is less likely to change frequently? |
| 51 |
|
| 52 |
> |
| 53 |
> A USE flag for what exactly? I'm not sure I understand you. |
| 54 |
|
| 55 |
Something like USE="install-local", which installs the package into |
| 56 |
/usr/local instead of /usr. |
| 57 |
In the default console settings this should override Apple provided |
| 58 |
packages, without leading to collisions. |
| 59 |
|
| 60 |
> You can manually install things to /usr/local and add them to |
| 61 |
> package.provided right now if you want to. Either way, lying to |
| 62 |
> portage about whats installed on a system is a bad idea, and always |
| 63 |
> leads to trouble. Portage package dependencies are just that, |
| 64 |
> dependencies on other packages in portage. So when an ebuilds has a |
| 65 |
> DEPEND="app-shells/bash", that means it wants/needs the bash in |
| 66 |
> portage, not a bash someone has done a ./configure && make && make |
| 67 |
> install on. |
| 68 |
|
| 69 |
I know about this, thats why I currently just played around with the idea. |
| 70 |
I think a USE="install-local" would allow to make sure that I get a proper |
| 71 |
emerge managed package, instead of a manual build. |
| 72 |
|
| 73 |
Regards |
| 74 |
Dirk |
| 75 |
|
| 76 |
-- |
| 77 |
gentoo-osx@g.o mailing list |
Archives