1 |
On Aug 29, 2005, at 5:30 AM, Finn Thain wrote: |
2 |
|
3 |
> |
4 |
> |
5 |
> On Mon, 29 Aug 2005, Grobian wrote: |
6 |
> |
7 |
>> Kito wrote: |
8 |
>>> |
9 |
>>> On Aug 27, 2005, at 4:32 PM, Grobian wrote: |
10 |
> |
11 |
> At the moment, ppc-macos would need the collision-protect feature, but |
12 |
> once we have a feature for prefixed installs, that should be used |
13 |
> instead |
14 |
> (by default, at least). |
15 |
> |
16 |
>>> The user interface would need to be hashed out as well of course. |
17 |
>>> How |
18 |
>>> do you install/bootstrap it? |
19 |
> |
20 |
> It would be nice to have ebuilds that could invoke the Darwin Build |
21 |
> Scripts (and merge the result on a ROOT). |
22 |
|
23 |
Yeap. already planned on using this to build a libSystem, etc. |
24 |
|
25 |
> |
26 |
> http://www.opendarwin.org/projects/darwinbuild/releases/ |
27 |
> |
28 |
> Given such ebuilds, surely catalyst can bootstrap it. |
29 |
> |
30 |
>>> Where is the local configuration data stored? This is an area that I |
31 |
>>> think would be acceptable to take some Mac OS specific indulgences, |
32 |
>>> such as plists for the main config data(prefix info, search paths, |
33 |
>>> etc), pkgs/dmgs to bootstrap/install, and I also think we should |
34 |
>>> abuse |
35 |
>>> the umbrella Framework mechanism when feasible. |
36 |
>> |
37 |
>> Wow, using plists would be a first start on getting portage widely |
38 |
>> accepted because it includes the buzz word XML. LOL. On a serious |
39 |
>> note, I think Apple has shown XML can work somehow. At least it |
40 |
>> has an |
41 |
>> open character, and it's great when you can 'script' your Keynote |
42 |
>> presentation by just doing string manipulation in a big XML file. |
43 |
>> |
44 |
>> So I would say, let's try to use this horrible XML on a pilot base |
45 |
>> for |
46 |
>> small configuration files. Maybe we should do it better than |
47 |
>> Apple at |
48 |
>> some point because their XML does not always make use of the tree |
49 |
>> structure of XML. For XML I would say: only deal with it if it looks |
50 |
>> appropriate for the case and it is relatively easy to extract the |
51 |
>> data |
52 |
>> (which is often very flat, as in the .plist files). |
53 |
> |
54 |
> I reckon XML is important, though perhaps not in the way you |
55 |
> describe. As |
56 |
> I see it, where ever portage is deployed as a secondary package |
57 |
> manager, |
58 |
> it needs to consult the primary one. That means that there needs to |
59 |
> be a |
60 |
> standard protocol for one package manager to query another. |
61 |
> |
62 |
|
63 |
I'm not sure I agree. I think this gets too close to a |
64 |
package.provided situation, portage will never know enough about |
65 |
another systems packages to map their functionality to its own. I |
66 |
think its preferable to let portage handle what it knows first hand |
67 |
before trying to force it data from a foreign host. |
68 |
|
69 |
> |
70 |
>> Let's indeed make it a 'native' application for OSX users. Native in |
71 |
>> the sense of how it installs and looks like. I may give file |
72 |
>> locations a |
73 |
>> thought today, but maybe I should know the Framework stuff a bit |
74 |
>> better |
75 |
>> first. Can we install the whole Gentoo stuff in a Framework? or |
76 |
>> is it |
77 |
>> better to just use a shortest path algorithm and end with /gentoo? |
78 |
>> Actually the user should be able to select a disk to install to |
79 |
>> during |
80 |
>> install... |
81 |
> |
82 |
> I reckon get it working (with an "upstream darwin" profile) in a |
83 |
> chroot |
84 |
> stage first (which could double as a boot disk). |
85 |
> |
86 |
|
87 |
I want to start a lot smaller than that first. Think stage1. You |
88 |
can't boot a stage1, its a just the corelibs and a toolchain pretty |
89 |
much. |
90 |
|
91 |
|
92 |
|
93 |
>>> The repo should never ever never ever EVER rely on anything it |
94 |
>>> doesn't know how to supply itself with, whether that be a tool, a |
95 |
>>> library, knowledge of a filesystem, a host, a protocol, whatever. It |
96 |
>>> doesn't matter how it gets it, it just needs to know at least one |
97 |
>>> way |
98 |
>>> to get it. This implies of course proper implementation of ferringbs |
99 |
>>> BDEPENDS idea. |
100 |
>> |
101 |
>> so, you mean if there is something (a filesystem) portage hasn't |
102 |
>> installed, then we should create the proper handles to deal with |
103 |
>> the OS |
104 |
>> provided one? As in create a compatibility tool for "fdisk.HFS |
105 |
>> +". I'm |
106 |
>> a bit clueless on how exactly you want to achieve what you want. |
107 |
>> Maybe |
108 |
>> I don't understand correctly what you want exactly too. |
109 |
> |
110 |
> This is how I would handle that case: |
111 |
> |
112 |
> If a program (say fsck_hfs) is available upstream, build it with Dawin |
113 |
> Build, merge it with portage (I expect an eclass for darwin build is |
114 |
> required, and of course an ebuild for diskdev_cmds.) |
115 |
|
116 |
About what I was thinking... |
117 |
|
118 |
>> |
119 |
>>> Binary packages have to work. Thats a fun one. But all this done |
120 |
>>> properly, should allow for at least a little more consistency |
121 |
>>> than the |
122 |
>>> current situation. I'm still sold on using xar[1] for this |
123 |
>>> despite the |
124 |
>>> rather heavy deps (they are deps I would want in most any |
125 |
>>> environment |
126 |
>>> anyway - libcurl,ssl,libxml,zlib), and it just fits the bill too |
127 |
>>> well |
128 |
>>> imho, support for most standard arch specific data such bsd flags, |
129 |
>>> ACLs, resource forks ,.etc as well an excellent TOC structure |
130 |
>>> that is |
131 |
>>> perfect for storing environment settings and package metadata. |
132 |
>> |
133 |
>> Again XML. If you do it XML, you have to do it all XML, something |
134 |
>> Apple |
135 |
>> apparently understood. It appears we will have the blessings if |
136 |
>> we use |
137 |
>> XML, so I think we should. In the end we can always dump all that |
138 |
>> XML |
139 |
>> into MonetDB/XQuery to have extremely fast querying over all the |
140 |
>> files, |
141 |
>> tree based. I think it would seriously be the first project to use |
142 |
>> XQuery and XML for it's configuration. However, if you come to |
143 |
>> think of |
144 |
>> it, it is a tree, an extensible tree, and might be a much more a |
145 |
>> logical |
146 |
>> choice than it appears to be. |
147 |
> |
148 |
> Why not use one of the open source .pkg tools to generate binary |
149 |
> packages? |
150 |
> Kito tells me he has already been able to unpack .pkg format and |
151 |
> install |
152 |
> it via portage. |
153 |
|
154 |
Thats just to get extract files...I'm talking about binary packages |
155 |
that portage can use. I don't like the current tbz2 hack. |
156 |
|
157 |
I have no interest personally in producing packages with a |
158 |
proprietary format for portage. Be a nice feature for OS X users and |
159 |
devs sure, but thats more like an add-on bells-and-whistles type |
160 |
feature... patches accepted ;) |
161 |
|
162 |
> |
163 |
>>> Avoid package.provided or anything of its likeness like the |
164 |
>>> plague. |
165 |
>>> This repo needs to describe a toolchain from the ground up, |
166 |
>>> regardless |
167 |
>>> of the host. "What CAN it build and how?", not "What WON'T the |
168 |
>>> host OS |
169 |
>>> let me do". |
170 |
>> |
171 |
>> Uhm, yes please! |
172 |
> |
173 |
> Hear, hear! |
174 |
> |
175 |
>>> Keep the number of ebuilds to a bare minimum. We can't get too |
176 |
>>> carried away with maintaining a complete tree, or we risk |
177 |
>>> drifting too |
178 |
>>> far downstream and the zealots pushing Darwin/Mac OS support out of |
179 |
>>> the main tree entirely. That would be bad. This can't go in the |
180 |
>>> direction of a fork, just an experimental branch that will be merged |
181 |
>>> back in at some point. |
182 |
> |
183 |
> IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt, |
184 |
> along-side os x and bsd. It isn't really a fork except in as much |
185 |
> as the |
186 |
> profile arrangement doesn't really accomodate work on darwin proper |
187 |
> (but |
188 |
> then the profile arrangemnet is flawed anyway: it only exists this way |
189 |
> because of the package.provided crutch). |
190 |
|
191 |
I was looking at it more as a place to develop some new portage |
192 |
features...Gentoo/Darwin has always been lurking, this is more in the |
193 |
area of just getting offsets working. |
194 |
|
195 |
> |
196 |
> -f |
197 |
> -- |
198 |
> gentoo-osx@g.o mailing list |
199 |
> |
200 |
|
201 |
-- |
202 |
gentoo-osx@g.o mailing list |