Re: [gentoo-osx] The road ahead?

[m h]

Kito-

Are you leveraging the work done by Haubi documented here:
http://gentoo-wiki.com/HOWTO_Use_prefixed_portage_%28in_development%29
???

Just wondering because I've been able to use this to get portage
installed on a FC4 system (I know it's not OSX).  But another user has
been able to use this to install over 200 packages on an AIX system.

matt

On 10/31/05, Kito <kito@g.o> wrote:
>
> 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
>
>

-- 
gentoo-osx@g.o mailing list