1 |
On Wed, 24 Aug 2005, Kito wrote: |
2 |
|
3 |
> |
4 |
> On Aug 24, 2005, at 12:09 PM, Finn Thain wrote: |
5 |
> > |
6 |
> >On Wed, 24 Aug 2005, Kito wrote: |
7 |
> > |
8 |
> > > >On Wed, 24 Aug 2005, Kito wrote: |
9 |
> > > > |
10 |
> > > > |
11 |
> > > >What I'm saying is that you cannot build Mac OS X, Apple will not |
12 |
> > > >permit that. If you wan't to install X Code, you have to script |
13 |
> > > >apple's installer to do it. That is 2nd fiddle. |
14 |
> > > |
15 |
> > >Erm, no. It installs by extracting the files from the installation |
16 |
> > >media similar to how other closed source software is installed via |
17 |
> > >portage, doom, UTK2004, vmware, etc. Maybe we have different ideas of |
18 |
> > >what 'second-fiddle' means. I interpret that as portage existing on a |
19 |
> > >system with a specified set of fake deps in package.provided. IMHO |
20 |
> > >portage is not second fiddle when it manages all files on the system. |
21 |
> > |
22 |
> >Porage still has to answer to the macos installer, for two reasons: |
23 |
> > |
24 |
> >- the macos installer will run around changing stuff without asking or |
25 |
> > telling portage (unless you can build a system without that |
26 |
> > installer). |
27 |
> |
28 |
> You can install macos without using installer(8). It is also possible to |
29 |
> manipulate installer(8) to install pkgs to non-boot volumes. |
30 |
|
31 |
Yes, indeed you can (I use ditto(8)). What I'm saying is that it isn't |
32 |
desirable to do so. The only exception that I can see is installing the |
33 |
macos installer itself. Doing this is a nice idea, and I've wanted to do |
34 |
the same thing, but I don't see this as being within the scope of Gentoo |
35 |
or Gentoo/OS X. |
36 |
|
37 |
BTW, to install enough of of macos to boostrap the macos installer doesn't |
38 |
require unpacking pkg files. Personally, (outside of the gentoo project) I |
39 |
would consider distributing a script that would tar up sufficient bits of |
40 |
macos. The tarball would then be used as a distfile on a Gentoo/Darwin |
41 |
system by an ebuild in an overlay. |
42 |
|
43 |
> > |
44 |
> >- most users don't want an OS X system without that installer (and |
45 |
> > software update). |
46 |
> |
47 |
> Most users don't what anything beyond what a default OS X install gives |
48 |
> them either...most users don't want portage either... there is no debate |
49 |
> on whether this is a small niche or not. |
50 |
|
51 |
Don't get me wrong, I'm not saying that what you are doing is misguided, |
52 |
I'm just saying that it shouldn't be among the goals of Gentoo. (If it |
53 |
were, then any dev/volunteer might be expected to support it.) |
54 |
|
55 |
I have said for a long time that _within_ the scope of the Gentoo/OS X |
56 |
project, Portage needs to be able to leverage installer(8) to install pkg |
57 |
files for packages that are closed source -- BUT only to provide deps for |
58 |
open source packages for which we have ebuilds (regardless of whether |
59 |
those ebuilds are XCode or configure/make). |
60 |
|
61 |
> > I'm not saying portage can't do it all (down to lipo-suctioning, |
62 |
> > creating Receipts files and all), I'm just saying that portage |
63 |
> > doesn't need to. I'd also say that Gentoo devs have better things to |
64 |
> > do than maintain tools to track a proprietary packaging system. |
65 |
> |
66 |
> Packages that portage handles don't need /Library/Receipts entries, |
67 |
> portage has its own db of package info. I'm definitely not implying |
68 |
> portage should/will be an installer(8) replacement. |
69 |
|
70 |
In the application you described, portage has to be an installer |
71 |
replacement or else the macos you have created is not equivalent to |
72 |
apple's macos, which leaves us back at the "ppc-macos" semantic problem. |
73 |
|
74 |
> Its merely a method of splitting up some of the system files into |
75 |
> smaller subsets than what Apple has provided in their install pkgs. |
76 |
> > |
77 |
> >IOW, I think it would be a mistake to try to upstage the soloist. |
78 |
> > |
79 |
> > > > >Even once prefixed installs are available I intend to continue |
80 |
> > > > >development in this area to facilitate extremely minimal OS X |
81 |
> > > > >installs for specialized applications. |
82 |
> > > > |
83 |
> > > >I applaud this. But I think calling that profile "macos" is a |
84 |
> > > >misnomer. |
85 |
> > > |
86 |
> > >Where do you draw the line? If during a macos install I choose not to |
87 |
> > >install all options available is it no longer macos proper? Macos to |
88 |
> > >me implies CoreFoundation, Quartz, and Aqua. Tons of other |
89 |
> > >closed-source frameworks make up MacOS as well of course, but if you |
90 |
> > >add CoreFoundation, Quartz, and Aqua to a Darwin system, its macos |
91 |
> > >IMHO. |
92 |
> > |
93 |
> >I didn't realise that you were unpacking the .pkgs without using |
94 |
> >/usr/sbin/installer. I can see why you would call such a profile macos. |
95 |
> > |
96 |
> >However, if I wanted binary packages, I wouldn't choose Gentoo, and I |
97 |
> >don't think it makes a lot of sense to have a profile called macos that |
98 |
> >doesn't build macos from source. This is, of course, impossible. |
99 |
> |
100 |
> Not sure I follow the logic there... This is what I have right now, |
101 |
> 'ROOT="/Volumes/Foobar" emerge system' compiles the opensource |
102 |
> components of Darwin and installs the needed frameworks to give you a |
103 |
> bootable, extremely minimal macos system with nothing more than whats |
104 |
> required to give you a WindowServer instance, and a loginwindow...no |
105 |
> iApps, no finder, no dock, no extraneous services, etc. etc. |
106 |
|
107 |
This is a fine hack, and I can see the benefits. But, I think it is out of |
108 |
scope of Gentoo in the sense that while portage should be flexible enough |
109 |
to accomodate this, the "portage for macos"/ppc-macos/2nd fiddle profile |
110 |
probably shouldn't have this among its official goals. The structuring of |
111 |
different profiles should have other considerations. |
112 |
|
113 |
> Useful? Not for anyone but me at this point, but its worked very well |
114 |
> for my purposes, which is having a dedicated DAW with a a very small |
115 |
> footprint. Before portage, I always did this manually by fiddling with |
116 |
> installer(8) and deleting all the extra stuff I didn't want.... I find |
117 |
> typing one command a lot more convenient. Down the road, I believe it |
118 |
> would also be useful for things like Kiosk installations etc., but we'll |
119 |
> see. |
120 |
> |
121 |
> > |
122 |
> > > >That's why I suggested calling upstream darwin, "ppc-darwin". The |
123 |
> > > >fact that it isn't called macos doesn't imply macos and macos |
124 |
> > > >packages cannot be supported on it. |
125 |
|
126 |
If you agree with my assertions about profiles and project scope above, |
127 |
does it not make sense to have "ppc-macos" mean those systems that can |
128 |
actually be called "Mac OS", i.e. Apple's one? |
129 |
|
130 |
Surely an "upstream darwin" profile (ppc-darwin or x86-darwin) would be |
131 |
the best place to bootstrap a non-Apple psuedo-macos install, like the |
132 |
ones described above? |
133 |
|
134 |
-f |
135 |
|
136 |
> > >The default-darwin profile is just that, though not currently a valid |
137 |
> > >profile with its own keyword, but all macos profiles inherit from |
138 |
> > >that. |
139 |
> > > |
140 |
> > >If you have a Darwin system with the closed source macos libs |
141 |
> > >installed, its no longer Darwin as it tends to all come back to the |
142 |
> > >difference between CoreFoundation(macos) and |
143 |
> > >CF-Lite(Darwin/OpenDarwin). I think I see what you are saying, I just |
144 |
> > >don't agree :p Anyway you look at it its all rather semantical, but |
145 |
> > >needs to be addressed nonetheless. |
146 |
> > |
147 |
> >Yep. |
148 |
> > |
149 |
> >Following your semantics, could "progressive" (ppc-macos) be likened to |
150 |
> >"2nd fiddle" (ppc-darwin), but without the prefix? |
151 |
> > |
152 |
> >-f |
153 |
> > |
154 |
> > >Of course, when apple finally gets fed up with the warez kiddies |
155 |
> > >running OS X on greybox crap and stops doing source releases, this |
156 |
> > >will all become irrelevant anyway :p |
157 |
> >-- gentoo-osx@g.o mailing list |
158 |
> > |
159 |
> |
160 |
> |
161 |
-- |
162 |
gentoo-osx@g.o mailing list |