Gentoo Archives: gentoo-osx

From: Kito <kito@g.o>
To: gentoo-osx@l.g.o
Cc: Brian Harring <ferringb@g.o>
Subject: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.
Date: Mon, 29 Aug 2005 16:48:36
In Reply to: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. by Finn Thain
On Aug 29, 2005, at 5:30 AM, Finn Thain wrote:

> > > On Mon, 29 Aug 2005, Grobian wrote: > >> Kito wrote: >>> >>> On Aug 27, 2005, at 4:32 PM, Grobian wrote: > > At the moment, ppc-macos would need the collision-protect feature, but > once we have a feature for prefixed installs, that should be used > instead > (by default, at least). > >>> The user interface would need to be hashed out as well of course. >>> How >>> do you install/bootstrap it? > > It would be nice to have ebuilds that could invoke the Darwin Build > Scripts (and merge the result on a ROOT).
Yeap. already planned on using this to build a libSystem, etc.
> > > > Given such ebuilds, surely catalyst can bootstrap it. > >>> Where is the local configuration data stored? This is an area that I >>> think would be acceptable to take some Mac OS specific indulgences, >>> such as plists for the main config data(prefix info, search paths, >>> etc), pkgs/dmgs to bootstrap/install, and I also think we should >>> abuse >>> the umbrella Framework mechanism when feasible. >> >> Wow, using plists would be a first start on getting portage widely >> accepted because it includes the buzz word XML. LOL. On a serious >> note, I think Apple has shown XML can work somehow. At least it >> has an >> open character, and it's great when you can 'script' your Keynote >> presentation by just doing string manipulation in a big XML file. >> >> So I would say, let's try to use this horrible XML on a pilot base >> for >> small configuration files. Maybe we should do it better than >> Apple at >> some point because their XML does not always make use of the tree >> structure of XML. For XML I would say: only deal with it if it looks >> appropriate for the case and it is relatively easy to extract the >> data >> (which is often very flat, as in the .plist files). > > I reckon XML is important, though perhaps not in the way you > describe. As > I see it, where ever portage is deployed as a secondary package > manager, > it needs to consult the primary one. That means that there needs to > be a > standard protocol for one package manager to query another. >
I'm not sure I agree. I think this gets too close to a package.provided situation, portage will never know enough about another systems packages to map their functionality to its own. I think its preferable to let portage handle what it knows first hand before trying to force it data from a foreign host.
> >> Let's indeed make it a 'native' application for OSX users. Native in >> the sense of how it installs and looks like. I may give file >> locations a >> thought today, but maybe I should know the Framework stuff a bit >> better >> first. Can we install the whole Gentoo stuff in a Framework? or >> is it >> better to just use a shortest path algorithm and end with /gentoo? >> Actually the user should be able to select a disk to install to >> during >> install... > > I reckon get it working (with an "upstream darwin" profile) in a > chroot > stage first (which could double as a boot disk). >
I want to start a lot smaller than that first. Think stage1. You can't boot a stage1, its a just the corelibs and a toolchain pretty much.
>>> The repo should never ever never ever EVER rely on anything it >>> doesn't know how to supply itself with, whether that be a tool, a >>> library, knowledge of a filesystem, a host, a protocol, whatever. It >>> doesn't matter how it gets it, it just needs to know at least one >>> way >>> to get it. This implies of course proper implementation of ferringbs >>> BDEPENDS idea. >> >> so, you mean if there is something (a filesystem) portage hasn't >> installed, then we should create the proper handles to deal with >> the OS >> provided one? As in create a compatibility tool for "fdisk.HFS >> +". I'm >> a bit clueless on how exactly you want to achieve what you want. >> Maybe >> I don't understand correctly what you want exactly too. > > This is how I would handle that case: > > If a program (say fsck_hfs) is available upstream, build it with Dawin > Build, merge it with portage (I expect an eclass for darwin build is > required, and of course an ebuild for diskdev_cmds.)
About what I was thinking...
>> >>> Binary packages have to work. Thats a fun one. But all this done >>> properly, should allow for at least a little more consistency >>> than the >>> current situation. I'm still sold on using xar[1] for this >>> despite the >>> rather heavy deps (they are deps I would want in most any >>> environment >>> anyway - libcurl,ssl,libxml,zlib), and it just fits the bill too >>> well >>> imho, support for most standard arch specific data such bsd flags, >>> ACLs, resource forks ,.etc as well an excellent TOC structure >>> that is >>> perfect for storing environment settings and package metadata. >> >> Again XML. If you do it XML, you have to do it all XML, something >> Apple >> apparently understood. It appears we will have the blessings if >> we use >> XML, so I think we should. In the end we can always dump all that >> XML >> into MonetDB/XQuery to have extremely fast querying over all the >> files, >> tree based. I think it would seriously be the first project to use >> XQuery and XML for it's configuration. However, if you come to >> think of >> it, it is a tree, an extensible tree, and might be a much more a >> logical >> choice than it appears to be. > > Why not use one of the open source .pkg tools to generate binary > packages? > Kito tells me he has already been able to unpack .pkg format and > install > it via portage.
Thats just to get extract files...I'm talking about binary packages that portage can use. I don't like the current tbz2 hack. I have no interest personally in producing packages with a proprietary format for portage. Be a nice feature for OS X users and devs sure, but thats more like an add-on bells-and-whistles type feature... patches accepted ;)
> >>> Avoid package.provided or anything of its likeness like the >>> plague. >>> This repo needs to describe a toolchain from the ground up, >>> regardless >>> of the host. "What CAN it build and how?", not "What WON'T the >>> host OS >>> let me do". >> >> Uhm, yes please! > > Hear, hear! > >>> Keep the number of ebuilds to a bare minimum. We can't get too >>> carried away with maintaining a complete tree, or we risk >>> drifting too >>> far downstream and the zealots pushing Darwin/Mac OS support out of >>> the main tree entirely. That would be bad. This can't go in the >>> direction of a fork, just an experimental branch that will be merged >>> back in at some point. > > IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt, > along-side os x and bsd. It isn't really a fork except in as much > as the > profile arrangement doesn't really accomodate work on darwin proper > (but > then the profile arrangemnet is flawed anyway: it only exists this way > because of the package.provided crutch).
I was looking at it more as a place to develop some new portage features...Gentoo/Darwin has always been lurking, this is more in the area of just getting offsets working.
> > -f > -- > gentoo-osx@g.o mailing list >
-- gentoo-osx@g.o mailing list


Subject Author
Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. Finn Thain <fthain@××××××××××××××××.au>