Re: [gentoo-osx] The road ahead?

[Kito]

On Oct 30, 2005, at 4:49 AM, Grobian wrote:

> Since it "is silly if you want things to work before several years
> off"
> [1], perhaps it's not that useful to discuss this issue.  However, we
> can all dream, can't we, so let's just do it(tm).
>
> I will try to carve a few roads in the sand in this mail that should
> somehow reflect what I think the things to discuss are, if we really
> want to get moving towards our holy grail.  Considering [1], this
> might
> be all useless afterward, but ok.
>
> 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'.

>
> Both two targets require some extra explanation.
> 1. Gentoo for OSX functions as "black sheep" of the Gentoo family.  In
>    that way we put a spell on not only ourselves, but also on the
>    Gentoo/Alt project -- which is a good candidate for the second
> black
>    sheep.  It may be just that some people don't like the smell of non
>    GNU/Linux stuff, but there are also constructive comments which
>    cannot be denied.
>    - My current stategy is to just show some goodwill, by for instance
>      reacting swift and accurate to security bugs, as my impression is
>      that those have been ignored in the past.  But not only securty
>      bugs, all bugs where we get involved I try to react within
>      reasonable time, just to show we care.  Well I do.  Of course any
>      support in this gets a warm welcome from me.
>    - In cooperation with others (mostly vapier) I try to reduce the
>      ebuild "spam" caused by ppc-macos.  An example is the big
>      anti conditional bug [2] which unfortunately hasn't got much of
>      my attention yet.  The idea is simple: make unconditional stuff
>      just to ease maintenance and keep ebuilds slim and pure.
> 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...

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

> in the mean-while I try to cope with
>      the bugfloods ;).  Keywording the low-hanging fruit (those
> ebuilds
>      with little or none USE-flags that just compile out of the box)
>      reduces the number of open bugs and should be ok when in a prefix
>      too.  Having more keyworded in portage prepares us a bit for the
>      grand "Fink challenge" too.
>    - To reach a good quality we will have to reenable the normal
>      keywording scheme again.  This will only be done once we have a
>      prefixed installer.  From that point, the imlate scripts and such
>      count for us too.  Problem there is that we will have to maintain
>      the whole tree, like for instance the AMD64 guys do.  We're
>      outnumbered and hence I think we could use some extra devs that
>      have more free time on their hands than most of us now.

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.

>
> 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?"

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

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.

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