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
In Reply to: Re: [gentoo-osx] On keywording ppc-macos by Kito
On Wed, 24 Aug 2005, Kito wrote:

> > On Aug 24, 2005, at 12:09 PM, Finn Thain wrote: > > > >On Wed, 24 Aug 2005, Kito wrote: > > > > > >On Wed, 24 Aug 2005, Kito wrote: > > > > > > > > > > > >What I'm saying is that you cannot build Mac OS X, Apple will not > > > >permit that. If you wan't to install X Code, you have to script > > > >apple's installer to do it. That is 2nd fiddle. > > > > > >Erm, no. It installs by extracting the files from the installation > > >media similar to how other closed source software is installed via > > >portage, doom, UTK2004, vmware, etc. Maybe we have different ideas of > > >what 'second-fiddle' means. I interpret that as portage existing on a > > >system with a specified set of fake deps in package.provided. IMHO > > >portage is not second fiddle when it manages all files on the system. > > > >Porage still has to answer to the macos installer, for two reasons: > > > >- the macos installer will run around changing stuff without asking or > > telling portage (unless you can build a system without that > > installer). > > You can install macos without using installer(8). It is also possible to > manipulate installer(8) to install pkgs to non-boot volumes.
Yes, indeed you can (I use ditto(8)). What I'm saying is that it isn't desirable to do so. The only exception that I can see is installing the macos installer itself. Doing this is a nice idea, and I've wanted to do the same thing, but I don't see this as being within the scope of Gentoo or Gentoo/OS X. BTW, to install enough of of macos to boostrap the macos installer doesn't require unpacking pkg files. Personally, (outside of the gentoo project) I would consider distributing a script that would tar up sufficient bits of macos. The tarball would then be used as a distfile on a Gentoo/Darwin system by an ebuild in an overlay.
> > > >- most users don't want an OS X system without that installer (and > > software update). > > Most users don't what anything beyond what a default OS X install gives > them either...most users don't want portage either... there is no debate > on whether this is a small niche or not.
Don't get me wrong, I'm not saying that what you are doing is misguided, I'm just saying that it shouldn't be among the goals of Gentoo. (If it were, then any dev/volunteer might be expected to support it.) I have said for a long time that _within_ the scope of the Gentoo/OS X project, Portage needs to be able to leverage installer(8) to install pkg files for packages that are closed source -- BUT only to provide deps for open source packages for which we have ebuilds (regardless of whether those ebuilds are XCode or configure/make).
> > I'm not saying portage can't do it all (down to lipo-suctioning, > > creating Receipts files and all), I'm just saying that portage > > doesn't need to. I'd also say that Gentoo devs have better things to > > do than maintain tools to track a proprietary packaging system. > > Packages that portage handles don't need /Library/Receipts entries, > portage has its own db of package info. I'm definitely not implying > portage should/will be an installer(8) replacement.
In the application you described, portage has to be an installer replacement or else the macos you have created is not equivalent to apple's macos, which leaves us back at the "ppc-macos" semantic problem.
> Its merely a method of splitting up some of the system files into > smaller subsets than what Apple has provided in their install pkgs. > > > >IOW, I think it would be a mistake to try to upstage the soloist. > > > > > > >Even once prefixed installs are available I intend to continue > > > > >development in this area to facilitate extremely minimal OS X > > > > >installs for specialized applications. > > > > > > > >I applaud this. But I think calling that profile "macos" is a > > > >misnomer. > > > > > >Where do you draw the line? If during a macos install I choose not to > > >install all options available is it no longer macos proper? Macos to > > >me implies CoreFoundation, Quartz, and Aqua. Tons of other > > >closed-source frameworks make up MacOS as well of course, but if you > > >add CoreFoundation, Quartz, and Aqua to a Darwin system, its macos > > >IMHO. > > > >I didn't realise that you were unpacking the .pkgs without using > >/usr/sbin/installer. I can see why you would call such a profile macos. > > > >However, if I wanted binary packages, I wouldn't choose Gentoo, and I > >don't think it makes a lot of sense to have a profile called macos that > >doesn't build macos from source. This is, of course, impossible. > > Not sure I follow the logic there... This is what I have right now, > 'ROOT="/Volumes/Foobar" emerge system' compiles the opensource > components of Darwin and installs the needed frameworks to give you a > bootable, extremely minimal macos system with nothing more than whats > required to give you a WindowServer instance, and a > iApps, no finder, no dock, no extraneous services, etc. etc.
This is a fine hack, and I can see the benefits. But, I think it is out of scope of Gentoo in the sense that while portage should be flexible enough to accomodate this, the "portage for macos"/ppc-macos/2nd fiddle profile probably shouldn't have this among its official goals. The structuring of different profiles should have other considerations.
> Useful? Not for anyone but me at this point, but its worked very well > for my purposes, which is having a dedicated DAW with a a very small > footprint. Before portage, I always did this manually by fiddling with > installer(8) and deleting all the extra stuff I didn't want.... I find > typing one command a lot more convenient. Down the road, I believe it > would also be useful for things like Kiosk installations etc., but we'll > see. > > > > > > >That's why I suggested calling upstream darwin, "ppc-darwin". The > > > >fact that it isn't called macos doesn't imply macos and macos > > > >packages cannot be supported on it.
If you agree with my assertions about profiles and project scope above, does it not make sense to have "ppc-macos" mean those systems that can actually be called "Mac OS", i.e. Apple's one? Surely an "upstream darwin" profile (ppc-darwin or x86-darwin) would be the best place to bootstrap a non-Apple psuedo-macos install, like the ones described above? -f
> > >The default-darwin profile is just that, though not currently a valid > > >profile with its own keyword, but all macos profiles inherit from > > >that. > > > > > >If you have a Darwin system with the closed source macos libs > > >installed, its no longer Darwin as it tends to all come back to the > > >difference between CoreFoundation(macos) and > > >CF-Lite(Darwin/OpenDarwin). I think I see what you are saying, I just > > >don't agree :p Anyway you look at it its all rather semantical, but > > >needs to be addressed nonetheless. > > > >Yep. > > > >Following your semantics, could "progressive" (ppc-macos) be likened to > >"2nd fiddle" (ppc-darwin), but without the prefix? > > > >-f > > > > >Of course, when apple finally gets fed up with the warez kiddies > > >running OS X on greybox crap and stops doing source releases, this > > >will all become irrelevant anyway :p > >-- gentoo-osx@g.o mailing list > > > >
-- gentoo-osx@g.o mailing list