Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-osx
Navigation:
Lists: gentoo-osx: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-osx@g.o
From: Finn Thain <fthain@...>
Subject: Re: Some Introduction
Date: Mon, 8 Aug 2005 16:52:03 +1000 (EST)
On Mon, 8 Aug 2005, Kito wrote:

> 
> On Aug 7, 2005, at 11:48 PM, Finn Thain wrote:
> 
> >
> >On Sun, 7 Aug 2005, Kito wrote:
> >
[snip]
> > >
> > >Well, my basic feeling is the current method of trying to accommodate
> > >Apple supplied userland is futile, its working against the advantages of
> > >the portage tree.
> > >
> >
> >Grobain, he reason this approach was taken (and this can be found in the
> >list archives and forum), was that there was no alternative. The mythical
> >pathspec was supposed to provide it. And, significantly, pathspec wasn't
> >going to be needed to have a Gentoo/Darwin distro, anyway.
> >
> >Kito, because of Gentoo/Darwin, this is not futile. And it saves space on
> >your own machine.
> 
> Maybe you misunderstood, what I think is futile is trying to avoid overwriting
> files, and accommodating things portage has no knowledge of or control over.

Yes. Collision-protect was always a hack. Far better to do prefixed 
installs for those that want Gentoo to play second-class citizen to OS X.

> >OS X has a decent binary package manager, why not exploit it? Updating 
> >a dot release on OS X is easier than emerge -Du system.
> 
> Because relying on Apples proprietary stuff is asking for trouble, its 
> liable to change at any given moment without notice.

Once the ebuilds for Apple's stuff are in the tree, maybe we could update 
package.provided from /Library/Receipts automatically?

> However, emerge'ing from .pkgs is in testing as we speak...

Nice!

> 
> >
> >And if portage acquires the ability to pull deps from several prefixes 
> >(which is apparently part of the plan) it sacrifices nothing to use OS 
> >X deps.
> 
> It sacrifices huge amounts of manhours, ebuild consistency

Intuitively, it seems to me that maybe 80% of the logic in the average 
ebuild is relevant to the package and doesn't relate to the platform. 
(Most free software is highly portable.) The remainder of the ebuild is 
either Gentoo specific or Gentoo/Linux specific.

Now obviously, the Linux specific bits are the problem, but it isn't just 
Gentoo/OS X and Gentoo/Darwin with this problem, it is the other two 
"red-headed stepchildren" as well -- Solaris and BSD. So it is not as if 
you are facing the Linux-specific-logic burden alone. More importantly, 
this logic can be fixed piecemeal over time, one ebuild at a time, no? 

I'm sure the above is not new to you, and I admit to being ignorant of the 
extent of the problems you are dealing with.

> and again, what works with apples current releases will probably not 
> work in future releases...Its pretty hard to second guess at team of >30 
> engineers on a project without live cvs...

This is very true, Apple doesn't have a great record for backward 
compatibilty in OS X. But, let's face it. No-one can reasonably expect 
every ebuild to keep working after they update their OS. The sad fact is 
that they will anyway, and that creates a support issue for you.

What to do? Maybe we could have a file in the profile to say that a given 
vendor package whose version exceeds a certain upper bound should be 
ignored, unless ~ppc-macos was in effect. i.e. the OS X dep would 
effectively disappear (or block?) unless the user did an emerge sync after 
Software Update, by which time the problem might be fixed in the tree.

On second thoughts, I wouldn't overload package.provided with this 
functionality. I'd probably have an automatically generated 
/etc/portage/profile/vendor.provided and a dev issued 
/etc/make.profile/vendor.stable...

> 
> >
> > >All the apps in portage are tested/tweaked/hacked/patched/whatever to 
> > >work with THE APPS IN PORTAGE, not with 3rd party software supplied 
> > >by arbitrary vendors.
> > >
> >
> >There are two problems here: one is the vendor deps, i.e. the present 
> >practice of package.providing deps that are not equivalent to the ones 
> >OS X provides. This problem goes away as soon as we get ebuilds that 
> >can produce some of apples opensource packages that we use as deps. 
> >Apple being apple, this was always a big ask, but darwinbuild should 
> >help.
> 
> I don't think the problem goes away as much as it changes, although for 
> the better IMHO and this is one of the very things I work on frequently. 
> darwinbuild is a great tool, I've watched it grow and helped hack on it 
> a little bit. Still not quite sure how it will fit into portage in the 
> long run...

It may not need integration into portage. Perhaps what is needed is an 
ebuild to install it and create the chroot, plus an eclass to allow an 
apple package to get itself built by darwinbuild?

[snip]
> > >
> > >My personal goals for the project in order of my interest:
> > >
> > > A self-hosting Darwin OS build-able and maintainable via portage
> > >
> >
> >Would you use a GNU userland (like GNU/Darwin) or an apple one (like 
> >OpenDarwin and OS X)?
> 
> Probably somewhere in between. I have the base system building right 
> now, slowly getting some of apples patches into things like python, 
> bash, bsdmake, etc.

Wow, this is great.

It would also be cool to have an Darwin system that could emerge itself 
from stage1 using Apple sources, where the stage1 tarball included 
darwinbuild. If only I had time to hack on this...

-f
-- 
gentoo-osx@g.o mailing list


References:
Some Introduction
-- Grobian
Re: Some Introduction
-- Kito
Re: Some Introduction
-- Finn Thain
Re: Some Introduction
-- Kito
Navigation:
Lists: gentoo-osx: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Some Introduction
Next by thread:
Re: Some Introduction
Previous by date:
Re: Some Introduction
Next by date:
Re: Some Introduction


Updated Jun 17, 2009

Summary: Archive of the gentoo-osx mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.