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
--
[email protected] mailing list
