Re: [gentoo-osx] Some Introduction

[Finn Thain]

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