Gentoo Archives: gentoo-osx

From: Finn Thain <fthain@××××××××××××××××.au>
To: gentoo-osx@l.g.o
Subject: Re: [gentoo-osx] On keywording ppc-macos
Date: Thu, 25 Aug 2005 04:15:29
Message-Id: Pine.LNX.4.63.0508251336490.7422@loopy.telegraphics.com.au
In Reply to: Re: [gentoo-osx] On keywording ppc-macos by Kito
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