Re: [gentoo-osx] The road ahead?

[Grobian]

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.

>> 2. A prefixed install for me means having a way to install into
>>    /Library/Gentoo, /Gentoo, /Users/Library/Gentoo or wherever.  I don't
>>    really care about the location, and a system wide install would be
>>    fine with me too.  I envision that a touch discussion on variable
>>    prefixes, or homedir prefixes and whatever will follow if not yet
>>    have been on the portage channels.  What I would like to see is that
>>    we can play with it, maybe not in its ideal state, but those
>>    improvements can be made while we're playing.
>
> My impression is everyone in the OS X team feels this is something thats
> going to get immaculately implemented by the portage gods, leaving us to
> reap the benefits.... not likely... If we don't do the work, no one
> will. I've been trying for months to no avail to get others involved so
> we can start 'playing with it'. Can lead a horse to water but can't make
> him drink I suppose...

Hmmm...  Yeah... Well I don't know what to say.  Of course you're right 
in the first part.  The reason I let it slide was that I couldn't cope 
with you guys to stick up-to-date.  I really regret to hear your 
complaint only now.  Not that I think I can change it much, again, I am 
a limited edition (in multiple ways ;) ).

>>    - Although I have seen signals that we're close to something like
>>      this (kudos to Kito and Brian)
>
> I have a self-hosting toolchain working in a prefix right now. Tons of
> bugs, tons of things not implemented yet, etc. etc. but its a solid
> start. Keep in mind, this should only be considered a proof-of-concept,
> mainly to help determine the requirements of the ebuilds when working in
> a prefixed environment.
>
> My rough plan is to squash a few of the major bugs left
> (collision-protect and binpkgs primarily), with brians help roll a new
> patch against current stable portage(using rc4 currently), check my
> overlay into the alt svn module, create a "developers preview" install
> pkg, and then continue adding ebuilds to the EAPI=1 overlay, adding
> features/bug squashing as we go. Once the overlay is in a fairly
> workable state, we can start/continue the beloved GLEP/Flaming process
> we all know and love.
>
> Brian has better insight than I on the long-term roadmap, so hopefully
> he'll chime in here, but my guess is the very very earliest we could see
> prefixed support in mainline would be around the time of saviours(3.0)
> official release... but in the meantime there is by no means any
> shortage of work to be done...
>
> All that being said, the more people working towards this same goal, the
> higher the probability of its success and eventual adoption by Gentoo
> proper.

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 just say this because I think you are the one with the knowledge here. 
  Feel free to post regular updates of the ongoing work, bottle-necks, 
issues and where work is needed to the list.

> 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.

>> 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.

> 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?  Its not *my* fault that 
we're in the mess we're in.  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.  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.

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.


-- 
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
-- 
gentoo-osx@g.o mailing list