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
> (by default, at least).
>>> The user interface would need to be hashed out as well of course.
>>> 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
>>> 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
>> 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
>> (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
> 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
>> 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
> I reckon get it working (with an "upstream darwin" profile) in a
> 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
>>> 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
>>> 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.
>> 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 for this
>>> despite the
>>> rather heavy deps (they are deps I would want in most any
>>> anyway - libcurl,ssl,libxml,zlib), and it just fits the bill too
>>> 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
>> 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
>> into MonetDB/XQuery to have extremely fast querying over all the
>> 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
>> choice than it appears to be.
> Why not use one of the open source .pkg tools to generate binary
> Kito tells me he has already been able to unpack .pkg format and
> 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
>>> This repo needs to describe a toolchain from the ground up,
>>> 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
> 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.
> firstname.lastname@example.org mailing list
email@example.com mailing list