Re: [gentoo-osx] The road ahead?

[Kito]

On Oct 31, 2005, at 1:34 PM, Grobian wrote:

> Kito wrote:
>>> My personal targets for this project are as follows:
>>> 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo
>>> family.
>>> 2. Get a prefixed install to make Gentoo for OSX comparative to
>>> Fink and
>>>    Darwin Ports, and quality wise go beyond.
>> Why (2) is not first on everyones priority list, I really don't
>> understand. If we can do (2) in a reasonably sane fashion, (1)
>> will 'just happen'.
>
> Well.  Not that I don't agree with you, but I don't have as much of
> a good indication how far away we are from the holy grail.  Hence,
> in the meanwhile while *I* have to wait for the long awaited gift
> from above, I try to fix those things that are possible without the
> prefix.  However, if I would have to chose between a prefixed
> portage next week, or getting a lot of ebuilds sane within a week,
> I wouldn't hestitate to go for the first one.  Hope this calms you
> down a bit ;)  I just reasoned from my own perspective as in what
> *I can* do.  I have limitations also.

This wasn't aimed directly at just you... I try to avoid using  
political jargon like saying 'everyone' when I mean one person in  
particular. In fact, you are the only person who *has* at least  
responded to my proposals on this in the past.  I really meant  
everyone(myself included). I didn't make prefixes a priority for  
myself either until a few months back when some of the dev seeds I  
was getting from apple made it blatantly obvious that relying on the  
moving target known as OS X is a dead-end. I really just feel  
spending my time getting prefixes closer to being a reality, is a  
much bigger benefit to the project than getting app-obscure/ 
widget-5.0 keyworded ppc-macos and closing a bug.

>
> Would you like to lead this sub-project, define roles, tasks and
> roll out a todo list or some minimalistic readme, so people can get
> involved and perhaps start wondering around in the code?

I'm not sure it warrants a sub-project, but if the consensus is that  
it does, I suppose I could lead it if noone else wants to. Hopefully  
I'll have some stuff to post in the coming week - an xml project  
page, very very rough 'getting started' doc, a prefixed os x  
stage1/3, pkg installer, and overlay snapshot. Considering the  
fragile nature of it all, and that whatever we/I come up with will  
function merely as a working prototype, I'm not sure how 'official'  
it should really get...

>
>> Again, I think that once a product exists that is actually useful,
>> both devs and users a like will start showing up...bit of a
>> chicken/egg situation I know, but this is opensource, without a
>> strong userbase, we won't ever have a strong dev team.
>
> It is of a not so big concern of me now.  It is on the road ahead.
> In the end it's much easier to craft the very kernel of our project
> with a small team, IMHO.

Yes, we have talked about this before, and I think we are in complete  
agreement.

>
>>> To conclude a short note on various flavours of the project, such as
>>> progressive and darwin.  I am not interested in those myself.  My
>>> main
>>> focus is on the 'consumer product', which should be the mainline
>>> product, or the collision-protect profiles as they are called
>>> now.  The
>>> fact that I am not interested (yet) into these profiles, does not
>>> mean I
>>> will never support them.  I would just like to focus on getting the
>>> mainline (normal users) product going, then if people have a
>>> personal
>>> target to create a progressive profile for instance, I will not stop
>>> such development -- not even wondering on how I would be able to
>>> stop it
>>> anyway.  I consider one of my personal wishes for a 64-bit
>>> install to
>>> be a profile that should walk the same path like a progressive
>>> profile:
>>> it should wait till there is a working mainline product.
>> To follow that logic, why are we continuing to mark things ~ppc-
>> macos when we don't even have a working a mainline product? I look
>> at the progressive profile about the same as you look at mass
>> keywording for all of dirks bug reports..."Its not extremely
>> useful right now, but the work will have to be done at some point,
>> so why not now?"
>
> Because I still don't understand the idea of progressive, and I do
> understand myself a bit sometimes.  So for me, progressive is a
> skim that exists in bugzilla, but every bug assigned to progressive
> is basically dead.  ~ppc-macos is simply the testing side of the
> mainline product we have.

But again, without the progressive profile, this past weekend when it  
came time to get all the system packages merging, I would have been  
starting from square1, as opposed to being able to quickly take  
advantage of ~12 months of hard work. Had we/I not had this means of  
keywording packages that collide with apple files, I'd still be  
fighting with spanky on getting the bash ebuild darwin-safe, instead  
of tackling the global problems of getting prefixes working.

>
>> Building a prefixed stage1 went extremely quickly because most of
>> the base-system packages had already been ported to OS X via my
>> work with the base-system people(ok, mainly just spanky ;) on the
>> progressive profile(perl,bash,coreutils,gcc-
>> apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, etc.
>> etc.).  This attitude of 'we only support the consumer product' is
>> a good outward goal, but is also what IMHO contributed to the half-
>> assed nature of the current collision-protect profiles...i.e. "We
>> have a very short sighted implementation, that is a maintenance
>> nightmare, requires very heavy modifications to the tree, and has
>> virtually 0 appeal to both devs and users, but lets keep working
>> hard and try to get gaim and x-chat keyworded ppc-macos because
>> its what users want."
>
> Yeah, ok.  But do you have a better solution?

I believe I do yes... and I'm working on it :p

> Its not *my* fault that we're in the mess we're in.

I was by no means implying that it was your fault...

> I just try to use pure management logic at the moment.  Might be
> short sighted... but on the other hand, I'm not going to ask
> someone to wait a few months or maybe a year with going
> systematically through portage and check everything if it compiles
> or not.  I'm just very happy that such person wants to go through
> that horror.
>
>> What I'm saying is, darwin and progressive provide a testbed for
>> the bottom-up approach that we should have been taking from the
>> beginning.
>
> Don't blame me for what's not my fault.

I'm really not laying blame on any one person...

> It has *absolutely* no use to keep on telling what is wrong now at
> the moment.  The only way out of there is what ciarmn would like to
> see the best: remove the full ppc-macos keyword from the tree.
> Then what ciarmn wouldn't like so much to see is that you can start
> all over from scratch in an overlay.

I'm not sure I followed that thought.

>
> Stressing the importance of progressive or darwin is ok.  I won't
> deny you are right, but as a project in itself it is not of
> relevance.  It is implicit for me that you need the clean compiles
> in the prefix, but when you have that, I simply don't see what a
> progressive profile would bring in advantages.
> The mainline profile of prefixed installs is more or less what "-
> collision-protect" is now.  From a user perspective.
>
> Maybe I think way to simple for you, or with a too commercial
> vision.  I just think it's better to move, instead of sink away
> deeper in the sand.

Err...huh?

--Kito

-- 
gentoo-osx@g.o mailing list