1 |
On Mon, 29 Aug 2005, Grobian wrote: |
2 |
|
3 |
> Kito wrote: |
4 |
> > |
5 |
> > On Aug 27, 2005, at 4:32 PM, Grobian wrote: |
6 |
> > |
7 |
|
8 |
[snip] |
9 |
|
10 |
> |
11 |
> > Do the initial import of the minimum required packages from the main |
12 |
> > tree, which shouldn't be too hard, basically a stage1 (see a |
13 |
> > packages.build file in one of the linux profiles for instance) give or |
14 |
> > take some things. |
15 |
> > |
16 |
> > Create a new profile(s), which should probably be a complete tear |
17 |
> > down, Finn Thain has had some great suggestions in this area. FINN! |
18 |
> > Care to jump in here? |
19 |
> |
20 |
> ^^^ Finn ^^^ :D |
21 |
|
22 |
Sure. The idea was this profile inheriance tree: |
23 |
|
24 |
|
25 |
.-> ppc-od |
26 |
.-> ppc-darwin < |
27 |
/ `-> ppc-macos |
28 |
default-darwin < |
29 |
\ .-> x86-od |
30 |
`-> x86-darwin < |
31 |
`-> x86-macos |
32 |
|
33 |
|
34 |
The purpose being, "progressive" and "collision-protect" are best given |
35 |
their own profiles in order to avoid having ebuilds test for the |
36 |
"collision-protect" feature. |
37 |
|
38 |
So, I was advocating that an "upstream darwin" profile, {x86,ppc}-darwin, |
39 |
should be used for anything that didn't bow down to mac os. Hence, the |
40 |
ppc-macos profile would be taken to mean "behave as a secondary package |
41 |
manager: play nice with mac os, and test the mac os package database for |
42 |
dependencies, and use the mac os installer to install them if they are |
43 |
available in a .pkg". |
44 |
|
45 |
At the moment, ppc-macos would need the collision-protect feature, but |
46 |
once we have a feature for prefixed installs, that should be used instead |
47 |
(by default, at least). |
48 |
|
49 |
> > The user interface would need to be hashed out as well of course. How |
50 |
> > do you install/bootstrap it? |
51 |
|
52 |
It would be nice to have ebuilds that could invoke the Darwin Build |
53 |
Scripts (and merge the result on a ROOT). |
54 |
|
55 |
http://www.opendarwin.org/projects/darwinbuild/releases/ |
56 |
|
57 |
Given such ebuilds, surely catalyst can bootstrap it. |
58 |
|
59 |
> > Where is the local configuration data stored? This is an area that I |
60 |
> > think would be acceptable to take some Mac OS specific indulgences, |
61 |
> > such as plists for the main config data(prefix info, search paths, |
62 |
> > etc), pkgs/dmgs to bootstrap/install, and I also think we should abuse |
63 |
> > the umbrella Framework mechanism when feasible. |
64 |
> |
65 |
> Wow, using plists would be a first start on getting portage widely |
66 |
> accepted because it includes the buzz word XML. LOL. On a serious |
67 |
> note, I think Apple has shown XML can work somehow. At least it has an |
68 |
> open character, and it's great when you can 'script' your Keynote |
69 |
> presentation by just doing string manipulation in a big XML file. |
70 |
> |
71 |
> So I would say, let's try to use this horrible XML on a pilot base for |
72 |
> small configuration files. Maybe we should do it better than Apple at |
73 |
> some point because their XML does not always make use of the tree |
74 |
> structure of XML. For XML I would say: only deal with it if it looks |
75 |
> appropriate for the case and it is relatively easy to extract the data |
76 |
> (which is often very flat, as in the .plist files). |
77 |
|
78 |
I reckon XML is important, though perhaps not in the way you describe. As |
79 |
I see it, where ever portage is deployed as a secondary package manager, |
80 |
it needs to consult the primary one. That means that there needs to be a |
81 |
standard protocol for one package manager to query another. |
82 |
|
83 |
In the mac os case, we can write a shim to talk XML to portage. |
84 |
|
85 |
(BTW, a similar protocol, but allowing one package manager to _update_ |
86 |
another could be used to make a universal binary installer. But it would |
87 |
need rpm, apt-get, portage etc to all implement a standard XML protocol |
88 |
and API. But this is only really interesting in a closed source context. |
89 |
And I've digressed. Mentioning XML just reminded me.) |
90 |
|
91 |
> Let's indeed make it a 'native' application for OSX users. Native in |
92 |
> the sense of how it installs and looks like. I may give file locations a |
93 |
> thought today, but maybe I should know the Framework stuff a bit better |
94 |
> first. Can we install the whole Gentoo stuff in a Framework? or is it |
95 |
> better to just use a shortest path algorithm and end with /gentoo? |
96 |
> Actually the user should be able to select a disk to install to during |
97 |
> install... |
98 |
|
99 |
I reckon get it working (with an "upstream darwin" profile) in a chroot |
100 |
stage first (which could double as a boot disk). |
101 |
|
102 |
[snip] |
103 |
|
104 |
> > Some random broad philosophy/design goals that I think should be |
105 |
> > stated...: |
106 |
> > |
107 |
> > The repo should never ever never ever EVER rely on anything it |
108 |
> > doesn't know how to supply itself with, whether that be a tool, a |
109 |
> > library, knowledge of a filesystem, a host, a protocol, whatever. It |
110 |
> > doesn't matter how it gets it, it just needs to know at least one way |
111 |
> > to get it. This implies of course proper implementation of ferringbs |
112 |
> > BDEPENDS idea. |
113 |
> |
114 |
> so, you mean if there is something (a filesystem) portage hasn't |
115 |
> installed, then we should create the proper handles to deal with the OS |
116 |
> provided one? As in create a compatibility tool for "fdisk.HFS+". I'm |
117 |
> a bit clueless on how exactly you want to achieve what you want. Maybe |
118 |
> I don't understand correctly what you want exactly too. |
119 |
|
120 |
This is how I would handle that case: |
121 |
|
122 |
If a program (say fsck_hfs) is available upstream, build it with Dawin |
123 |
Build, merge it with portage (I expect an eclass for darwin build is |
124 |
required, and of course an ebuild for diskdev_cmds.) |
125 |
|
126 |
If a package (say macext2fs) is available as a .pkg or .dmg, download it |
127 |
with portage, and install it with mac os installer(8). Again, an eclass to |
128 |
handle these would be useful (this is probably how they are handled |
129 |
already?) |
130 |
|
131 |
> > Although we want this for ppc-macos at the moment, it should not be |
132 |
> > specific to either of those things, ppc, or macos. Adhering to this |
133 |
> > rule assumes a lot...again the BDEPENDS issue, and keeping as close to |
134 |
> > the main tree as possible, with those things in place, and done |
135 |
> > properly(i.e. what it REALLY takes to bootstrap an |
136 |
> > {x86,amd_64,ppc,ppc64,mips,sh,whatever}-{linux,*bsd,darwin,macos,whatever} |
137 |
> > toolchain) , you have a sane cross-compile ready repo, that is pretty |
138 |
> > damn portable. |
139 |
|
140 |
Darwin is not self-hosting (out of the box). You need a carefully |
141 |
contrived a build environment to make it so, and this is what the Darwin |
142 |
Build Scripts do: install that build environment, and automate the builds. |
143 |
|
144 |
Darwin build uses plists to describe all the packages in a mac os release, |
145 |
along with build dependencies, and so forth. These build dependencies are |
146 |
confined to the darwin build chroot, as I understand it. Portage wouldn't |
147 |
have to know about them, I think it just has to do the merge of the build |
148 |
product and install the runtime dependencies thereof (of course). |
149 |
|
150 |
> That would be really great. |
151 |
> |
152 |
> > Binary packages have to work. Thats a fun one. But all this done |
153 |
> > properly, should allow for at least a little more consistency than the |
154 |
> > current situation. I'm still sold on using xar[1] for this despite the |
155 |
> > rather heavy deps (they are deps I would want in most any environment |
156 |
> > anyway - libcurl,ssl,libxml,zlib), and it just fits the bill too well |
157 |
> > imho, support for most standard arch specific data such bsd flags, |
158 |
> > ACLs, resource forks ,.etc as well an excellent TOC structure that is |
159 |
> > perfect for storing environment settings and package metadata. |
160 |
> |
161 |
> Again XML. If you do it XML, you have to do it all XML, something Apple |
162 |
> apparently understood. It appears we will have the blessings if we use |
163 |
> XML, so I think we should. In the end we can always dump all that XML |
164 |
> into MonetDB/XQuery to have extremely fast querying over all the files, |
165 |
> tree based. I think it would seriously be the first project to use |
166 |
> XQuery and XML for it's configuration. However, if you come to think of |
167 |
> it, it is a tree, an extensible tree, and might be a much more a logical |
168 |
> choice than it appears to be. |
169 |
|
170 |
Why not use one of the open source .pkg tools to generate binary packages? |
171 |
Kito tells me he has already been able to unpack .pkg format and install |
172 |
it via portage. |
173 |
|
174 |
> > Avoid package.provided or anything of its likeness like the plague. |
175 |
> > This repo needs to describe a toolchain from the ground up, regardless |
176 |
> > of the host. "What CAN it build and how?", not "What WON'T the host OS |
177 |
> > let me do". |
178 |
> |
179 |
> Uhm, yes please! |
180 |
|
181 |
Hear, hear! |
182 |
|
183 |
package.provided must die. In the long run, it is not sustainable to |
184 |
attempt to use profiles to describe a moving target. If you do that, you |
185 |
end up with not one profile for 10.4, but profiles for 10.4, 10.4.1 and |
186 |
10.4.2 because, for example, 10.4.2 fixed a bug in apple's xyz package |
187 |
that forced apples xyz to be masked in the 10.4.1 profile. |
188 |
|
189 |
And then you still have the problem that the user may actually be running |
190 |
10.4.6, thanks to a recent Software Update, while the latest profile is at |
191 |
10.4.4, thanks to an old emerge --sync, all while /etc/make.profile is |
192 |
still a symlink to the 10.4.1 profile, thanks to the user neglecting to |
193 |
re-point it since installation! |
194 |
|
195 |
> > Keep the number of ebuilds to a bare minimum. We can't get too |
196 |
> > carried away with maintaining a complete tree, or we risk drifting too |
197 |
> > far downstream and the zealots pushing Darwin/Mac OS support out of |
198 |
> > the main tree entirely. That would be bad. This can't go in the |
199 |
> > direction of a fork, just an experimental branch that will be merged |
200 |
> > back in at some point. |
201 |
|
202 |
IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt, |
203 |
along-side os x and bsd. It isn't really a fork except in as much as the |
204 |
profile arrangement doesn't really accomodate work on darwin proper (but |
205 |
then the profile arrangemnet is flawed anyway: it only exists this way |
206 |
because of the package.provided crutch). |
207 |
|
208 |
-f |
209 |
-- |
210 |
gentoo-osx@g.o mailing list |