1 |
On Mon, 8 Aug 2005, Kito wrote: |
2 |
|
3 |
> |
4 |
> On Aug 7, 2005, at 11:48 PM, Finn Thain wrote: |
5 |
> |
6 |
> > |
7 |
> >On Sun, 7 Aug 2005, Kito wrote: |
8 |
> > |
9 |
[snip] |
10 |
> > > |
11 |
> > >Well, my basic feeling is the current method of trying to accommodate |
12 |
> > >Apple supplied userland is futile, its working against the advantages of |
13 |
> > >the portage tree. |
14 |
> > > |
15 |
> > |
16 |
> >Grobain, he reason this approach was taken (and this can be found in the |
17 |
> >list archives and forum), was that there was no alternative. The mythical |
18 |
> >pathspec was supposed to provide it. And, significantly, pathspec wasn't |
19 |
> >going to be needed to have a Gentoo/Darwin distro, anyway. |
20 |
> > |
21 |
> >Kito, because of Gentoo/Darwin, this is not futile. And it saves space on |
22 |
> >your own machine. |
23 |
> |
24 |
> Maybe you misunderstood, what I think is futile is trying to avoid overwriting |
25 |
> files, and accommodating things portage has no knowledge of or control over. |
26 |
|
27 |
Yes. Collision-protect was always a hack. Far better to do prefixed |
28 |
installs for those that want Gentoo to play second-class citizen to OS X. |
29 |
|
30 |
> >OS X has a decent binary package manager, why not exploit it? Updating |
31 |
> >a dot release on OS X is easier than emerge -Du system. |
32 |
> |
33 |
> Because relying on Apples proprietary stuff is asking for trouble, its |
34 |
> liable to change at any given moment without notice. |
35 |
|
36 |
Once the ebuilds for Apple's stuff are in the tree, maybe we could update |
37 |
package.provided from /Library/Receipts automatically? |
38 |
|
39 |
> However, emerge'ing from .pkgs is in testing as we speak... |
40 |
|
41 |
Nice! |
42 |
|
43 |
> |
44 |
> > |
45 |
> >And if portage acquires the ability to pull deps from several prefixes |
46 |
> >(which is apparently part of the plan) it sacrifices nothing to use OS |
47 |
> >X deps. |
48 |
> |
49 |
> It sacrifices huge amounts of manhours, ebuild consistency |
50 |
|
51 |
Intuitively, it seems to me that maybe 80% of the logic in the average |
52 |
ebuild is relevant to the package and doesn't relate to the platform. |
53 |
(Most free software is highly portable.) The remainder of the ebuild is |
54 |
either Gentoo specific or Gentoo/Linux specific. |
55 |
|
56 |
Now obviously, the Linux specific bits are the problem, but it isn't just |
57 |
Gentoo/OS X and Gentoo/Darwin with this problem, it is the other two |
58 |
"red-headed stepchildren" as well -- Solaris and BSD. So it is not as if |
59 |
you are facing the Linux-specific-logic burden alone. More importantly, |
60 |
this logic can be fixed piecemeal over time, one ebuild at a time, no? |
61 |
|
62 |
I'm sure the above is not new to you, and I admit to being ignorant of the |
63 |
extent of the problems you are dealing with. |
64 |
|
65 |
> and again, what works with apples current releases will probably not |
66 |
> work in future releases...Its pretty hard to second guess at team of >30 |
67 |
> engineers on a project without live cvs... |
68 |
|
69 |
This is very true, Apple doesn't have a great record for backward |
70 |
compatibilty in OS X. But, let's face it. No-one can reasonably expect |
71 |
every ebuild to keep working after they update their OS. The sad fact is |
72 |
that they will anyway, and that creates a support issue for you. |
73 |
|
74 |
What to do? Maybe we could have a file in the profile to say that a given |
75 |
vendor package whose version exceeds a certain upper bound should be |
76 |
ignored, unless ~ppc-macos was in effect. i.e. the OS X dep would |
77 |
effectively disappear (or block?) unless the user did an emerge sync after |
78 |
Software Update, by which time the problem might be fixed in the tree. |
79 |
|
80 |
On second thoughts, I wouldn't overload package.provided with this |
81 |
functionality. I'd probably have an automatically generated |
82 |
/etc/portage/profile/vendor.provided and a dev issued |
83 |
/etc/make.profile/vendor.stable... |
84 |
|
85 |
> |
86 |
> > |
87 |
> > >All the apps in portage are tested/tweaked/hacked/patched/whatever to |
88 |
> > >work with THE APPS IN PORTAGE, not with 3rd party software supplied |
89 |
> > >by arbitrary vendors. |
90 |
> > > |
91 |
> > |
92 |
> >There are two problems here: one is the vendor deps, i.e. the present |
93 |
> >practice of package.providing deps that are not equivalent to the ones |
94 |
> >OS X provides. This problem goes away as soon as we get ebuilds that |
95 |
> >can produce some of apples opensource packages that we use as deps. |
96 |
> >Apple being apple, this was always a big ask, but darwinbuild should |
97 |
> >help. |
98 |
> |
99 |
> I don't think the problem goes away as much as it changes, although for |
100 |
> the better IMHO and this is one of the very things I work on frequently. |
101 |
> darwinbuild is a great tool, I've watched it grow and helped hack on it |
102 |
> a little bit. Still not quite sure how it will fit into portage in the |
103 |
> long run... |
104 |
|
105 |
It may not need integration into portage. Perhaps what is needed is an |
106 |
ebuild to install it and create the chroot, plus an eclass to allow an |
107 |
apple package to get itself built by darwinbuild? |
108 |
|
109 |
[snip] |
110 |
> > > |
111 |
> > >My personal goals for the project in order of my interest: |
112 |
> > > |
113 |
> > > A self-hosting Darwin OS build-able and maintainable via portage |
114 |
> > > |
115 |
> > |
116 |
> >Would you use a GNU userland (like GNU/Darwin) or an apple one (like |
117 |
> >OpenDarwin and OS X)? |
118 |
> |
119 |
> Probably somewhere in between. I have the base system building right |
120 |
> now, slowly getting some of apples patches into things like python, |
121 |
> bash, bsdmake, etc. |
122 |
|
123 |
Wow, this is great. |
124 |
|
125 |
It would also be cool to have an Darwin system that could emerge itself |
126 |
from stage1 using Apple sources, where the stage1 tarball included |
127 |
darwinbuild. If only I had time to hack on this... |
128 |
|
129 |
-f |
130 |
-- |
131 |
gentoo-osx@g.o mailing list |