Mailing List Archive

On Oct 30, 2005, at 10:49 am, Grobian wrote:
>
> 2. Get a prefixed install to make Gentoo for OSX comparative to Fink
> and
> Darwin Ports, and quality wise go beyond.

As a Gentoo Linux and a Macintosh user this is very very important to
me - I think you hit the nail on the head.

Being familiar with Portage I didn't like Fink much when I used it;
there are CLI utilities that I miss on OS X and I'd install Gentoo-OSX
in a flash if I thought it was reasonably usable, but IMO the prefixed
install is essential for gaining user confidence (particularly
considering the caution of the average Mac user!).

> Having more keyworded in portage prepares us a bit for the grand "Fink
> challenge" too.

Good luck with that. Ulitmately I'd like to see Gentoo-OSX slay Fink
mercilessly & with gushing blood.

Stroller.

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

J4rg0n at gentoo

Oct 30, 2005, 10:25 PM

Post #3 of 58 (10375 views)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

If you want, I can re-enable the imlate script on my server. I
stopped it because I was under the impression that keeping up with
x86 was just not feasible for us. Perhaps this should wait until we
have prefixed installs?

For now, I think our best efforts (in terms of packages, not portage)
would be to increase upstream support for Darwin/Mac OS X. The more
we submit packages upstream, the more likely it is that future
versions of things will work without us tweaking them. That way, we
spend a bit more time initially fixing things, but we ultimately fix
it once.

- --Lina Pezzella
Gentoo Developer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFDZarJNJ9STR9DbYERAh4sAJ41Sp72VXda6zDQPDwxGcfcHbZewwCgzG9t
XrrBBf+1BGPeLhrcky4ATwE=
=ECpR
-----END PGP SIGNATURE-----
--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 11:52 AM

Post #4 of 58 (10377 views)

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@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 11:58 AM

Post #5 of 58 (10369 views)

Lina Pezzella wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Oct 30, 2005, at 5:49 AM, Grobian wrote:
>
> If you want, I can re-enable the imlate script on my server. I stopped
> it because I was under the impression that keeping up with x86 was just
> not feasible for us. Perhaps this should wait until we have prefixed
> installs?

Please wait with this, till it really becomes relevant again. Much
appreciated though.

> For now, I think our best efforts (in terms of packages, not portage)
> would be to increase upstream support for Darwin/Mac OS X. The more we
> submit packages upstream, the more likely it is that future versions of
> things will work without us tweaking them. That way, we spend a bit more
> time initially fixing things, but we ultimately fix it once.

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

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 12:34 PM

Post #6 of 58 (10374 views)

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@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 2:42 PM

Post #7 of 58 (10367 views)

dirk.schoenberger at sz-online

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@gentoo.org mailing list

The road ahead? [ In reply to ]

Oct 31, 2005, 3:17 PM

Post #8 of 58 (10400 views)

Just wanted to put my 2cent into the discussion.
I suppose I am currently just a pure Gentoo-OSX user, and while I see the
point of the prefix project, I am not really convinced by it. I like the
way Gentoo integrates into the system, or at least the part accessible by
a console.

I see this as an advantage above e.g. Fink, with its own namespace. The
namespace variant implies that I have to fudge around with PATH variables
and other CLI stuff, in order to get the apps working. I still have no
real MacOSX integration, with App folder and GUI starter elements (which
would be my biggest feature request)

From what I see as a user, the Gentoo packages divide into 4 categories

1) packages which integrate nicely into the system (no dependencies, or
dependencies which are properly provided by MacOS)
2) packages which clash with MacOS provided packages, things like python
or automake spring to mind
3) packages which depend on 2)
4) misc packages which are otherwise problematic. This means most of the
package.masked packages, where I cannot really speak about.

The biggest problem is obiously the packages in 2)

My private idea in order to emerge packages in 3) would currently be to
manually install the needed packages in places like /usr/local (instead of
Gentoos /usr) and put these packages into package.provided. It would be
really nice if I could use this way while still being able to use the
emerge functionaltiy. Perhaps this could be handled by a special USE flag?

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 3:20 PM

Post #9 of 58 (10366 views)

Kito wrote:
>> 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...

sub-project is as large as you want it to be. I didn't want to write
'project' because I don't want to refer to the Gentoo for OSX project as
a whole. This thing of portage with prefixes, that's what I meant and
it's yours.

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

Yes, but then I come in again from my management perspective, and I say:
"Progressive as in user product doesn't work!".

But really. The work you describe is pure development efforts (luckily)
spent before you could actually use it. It takes insight and
recognition to do something like that. Kudos to you to identify the
need upfront!

I would personally 'hide' it away behind a development thing, not cover
it under "this is for the real die hards that want bleeding edge stuff:
progressive". Because in the latter it isn't clear why you're doing it,
and some users might think it's simply *cool*. No, it should be a clear
development thing with development hazards, absolutely not meant for any
user, unless those that want to sacrifice and contribute their 'blood'.
Well, ok, that's my thinking.

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

It's IMHO just not an option. At least I won't allow you to do it. :)

Anyway, it's good to know that we're basically on the same route.

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

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 4:12 PM

Post #10 of 58 (10414 views)

dirk.schoenberger at sz-online

On Oct 31, 2005, at 4:17 PM, dirk.schoenberger@sz-online.de wrote:

> Just wanted to put my 2cent into the discussion.
> I suppose I am currently just a pure Gentoo-OSX user, and while I
> see the
> point of the prefix project, I am not really convinced by it. I
> like the
> way Gentoo integrates into the system, or at least the part
> accessible by
> a console.

Wow. You are in the minority in this I think.

A big part of the challenge in designing the beast, is it has to be
compatible with non-prefixed installs, and eventually even a non-
prefixed install on the same machine,... this is by no means a fork,
so portage installing packages to / is obviously not going to go away.

>
> I see this as an advantage above e.g. Fink, with its own namespace.
> The
> namespace variant implies that I have to fudge around with PATH
> variables
> and other CLI stuff, in order to get the apps working. I still have no
> real MacOSX integration, with App folder and GUI starter elements
> (which
> would be my biggest feature request)

The Portage take on this would be slightly different, as it will live
in its own space, with its own set of GUI accessible .apps,
Frameworks, etc. Can you elaborate on "I have to fudge around with
PATH variables and other CLI stuff" and "real MacOSX integration,
with App folder and GUI starter elements" please?

>
> From what I see as a user, the Gentoo packages divide into 4
> categories
>
> 1) packages which integrate nicely into the system (no
> dependencies, or
> dependencies which are properly provided by MacOS)

The problems with this have been outlined numerous times by both
users and devs, but to quickly re-hash them: It makes system backups/
reinstalls a pain, the deps that are 'properly' provided by apple can
and will change without notice, it requires manual mapping of faux-
deps via the profiles, a software update or `diskutil
repairPermissions /` can render your portage installed files useless,
its what keeps the project a laughable novelty to most Darwin/OS X
users and developers

> 2) packages which clash with MacOS provided packages, things like
> python
> or automake spring to mind
> 3) packages which depend on 2)
> 4) misc packages which are otherwise problematic. This means most
> of the
> package.masked packages, where I cannot really speak about.
>
> The biggest problem is obiously the packages in 2)
>
> My private idea in order to emerge packages in 3) would currently
> be to
> manually install the needed packages in places like /usr/local
> (instead of
> Gentoos /usr) and put these packages into package.provided. It
> would be
> really nice if I could use this way while still being able to use the
> emerge functionaltiy. Perhaps this could be handled by a special
> USE flag?

A USE flag for what exactly? I'm not sure I understand you. You can
manually install things to /usr/local and add them to
package.provided right now if you want to. Either way, lying to
portage about whats installed on a system is a bad idea, and always
leads to trouble. Portage package dependencies are just that,
dependencies on other packages in portage. So when an ebuilds has a
DEPEND="app-shells/bash", that means it wants/needs the bash in
portage, not a bash someone has done a ./configure && make && make
install on.

--Kito

P.S. Its good to see you are a human, I was starting to think you
were a clever bugzilla bot someone wrote to keep us busy ;)

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 4:49 PM

Post #11 of 58 (10369 views)

>>
>> I see this as an advantage above e.g. Fink, with its own namespace.
>> The
>> namespace variant implies that I have to fudge around with PATH
>> variables
>> and other CLI stuff, in order to get the apps working. I still have no
>> real MacOSX integration, with App folder and GUI starter elements
>> (which
>> would be my biggest feature request)
>
> The Portage take on this would be slightly different, as it will live
> in its own space, with its own set of GUI accessible .apps,
> Frameworks, etc. Can you elaborate on "I have to fudge around with
> PATH variables and other CLI stuff"

In a more Fink inspired way, I think I would have to add at lease a
PATH=$PATH:/sw/bin resp. the settings for LD_LIBRARY_PATH (or whatever the
Mac equivalent is)

> and "real MacOSX integration, with App folder and GUI starter elements"
please?

With this I mean anything which enables me to e.g start X based
application via the Finder, instead of from a command line. App folder
would e.g allow me to create a "standalone" application which I can put on
another machine, without having to re-install the whole Gentoo system. I
know that this somehow circumvent the whole reason of Gentoo, namely the
automatic maintenance and update of components and their dependent
applications.

>>
>> From what I see as a user, the Gentoo packages divide into 4
>> categories
>>
>> 1) packages which integrate nicely into the system (no
>> dependencies, or
>> dependencies which are properly provided by MacOS)
>
> The problems with this have been outlined numerous times by both
> users and devs, but to quickly re-hash them: It makes system backups/
> reinstalls a pain, the deps that are 'properly' provided by apple can
> and will change without notice, it requires manual mapping of faux-
> deps via the profiles, a software update or `diskutil
> repairPermissions /` can render your portage installed files useless,
> its what keeps the project a laughable novelty to most Darwin/OS X
> users and developers

I am not so long a member of the list, so thanks for the short repetition.
Is it possible to define some kind of "safe subset" of Apple provided
packages, i.e something which is less likely to change frequently?

>
> A USE flag for what exactly? I'm not sure I understand you.

Something like USE="install-local", which installs the package into
/usr/local instead of /usr.
In the default console settings this should override Apple provided
packages, without leading to collisions.

> You can manually install things to /usr/local and add them to
> package.provided right now if you want to. Either way, lying to
> portage about whats installed on a system is a bad idea, and always
> leads to trouble. Portage package dependencies are just that,
> dependencies on other packages in portage. So when an ebuilds has a
> DEPEND="app-shells/bash", that means it wants/needs the bash in
> portage, not a bash someone has done a ./configure && make && make
> install on.

I know about this, thats why I currently just played around with the idea.
I think a USE="install-local" would allow to make sure that I get a proper
emerge managed package, instead of a manual build.

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

sesquile at gmail

Oct 31, 2005, 5:16 PM

Post #12 of 58 (10356 views)

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@gentoo.org> 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@gentoo.org mailing list
>
>

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

ferringb at gentoo

Oct 31, 2005, 5:32 PM

Post #13 of 58 (10361 views)

On Mon, Oct 31, 2005 at 04:16:44PM -0800, m h wrote:
> Kito-
>
> Are you leveraging the work done by Haubi documented here:
> http://gentoo-wiki.com/HOWTO_Use_prefixed_portage_%28in_development%29

Yah, although differs in certain respects;

1) affix doesn't exist
2) bound to a temp EAPI to use for masking non prefix capable ebuilds
3) Strict paths. *really* strict.
4) by hand reimplementation of the python side of the modifications
5) stable based. the patch referenced is 2.1; I (mostly by hand I'm
afraid) backported the relevant chunks, rewriting what was needed and
simplifying it down a bit (affix removal fex).

There is common code between them, but right now the prefix patch I've
been splitting off of 2.0.51-rc4 is the simple cousin of haubi's work,
round two basically, with a lot of patch monkeying via kito/myself to
iron the beast out.

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

Should be usable in both cases. Literally, the prefix stable patch is
chunks of my 2.1 work and haubi's work torn out and integrated into 2.0
for prototype demonstration. Exempting the AFFIX difference, should
work in a similar fashion across systems, although haubi's stage0 work
is a seperate thing.

~harring

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 5:51 PM

Post #14 of 58 (10351 views)

On Oct 31, 2005, at 6:16 PM, m h wrote:

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

Yeah, Brian backported his 2.1 patch to 2.0, and we've had some
additional changes like strict PATH handling(portage requires the
toolchain to live in ${PREFIX}), no use of ${AFFIX} (save that for
later, when portage can manage interdomain deps), ${D} and ${ROOT}
autoexpanded to ${BUILDDIR}/image/${PREFIX} in the ebuild env to
limit the required changes to ebuilds, addition of the ${DEST}
variable for make install DESTDIR targets, also some extra ebuild.sh
functions for setting custom bindir,infodir,sysconf,libdir
configuration options in non-econf configured ebuilds, and various
do* utils fixes.

As it sits right now, the ebuild changes required are very very
minor, which is of utmost importance if this is ever going to fly.

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

Excellent. As I mentioned earlier, later this week I hope to get some
barebones docs and the overlay checked into the alt svn repo. The
current method will require arch specific tarballs, so hopefully we
can coordinate effort on this as I've only been targeting Darwin/
OSX... the more portable it is, the better.

--Kito

>
> matt
>
> On 10/31/05, Kito <kito@gentoo.org> 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@gentoo.org mailing list
>>
>>
>
> --
> gentoo-osx@gentoo.org mailing list
>

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Oct 31, 2005, 5:59 PM

Post #15 of 58 (10362 views)

On Oct 31, 2005, at 6:32 PM, Brian Harring wrote:

> On Mon, Oct 31, 2005 at 04:16:44PM -0800, m h wrote:
>
> Should be usable in both cases. Literally, the prefix stable patch is
> chunks of my 2.1 work and haubi's work torn out and integrated into
> 2.0
> for prototype demonstration.

Those last 2 words should be stressed... don't want anyone getting
false ideas of whats being done here...

> Exempting the AFFIX difference, should
> work in a similar fashion across systems, although haubi's stage0 work
> is a seperate thing.

Yeah, I'm pretty much finished with the base-system packages, so a
traditional prefixed stage{1,3} can take the place of haubis stage0/
toolsbox stuff. Of course you still need to bootstrap manually if you
want a different default prefix than whatever the stage builders
used. For Darwin/OS X, I'm leaning towards using /Library/Portage as
the default prefix, not sure about what would be preferable for other
systems. /opt might be a good choice, but for reasons I can't really
clarify yet, a unique namespace seems better suited...but I digress.

--Kito

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

sesquile at gmail

Oct 31, 2005, 6:20 PM

Post #16 of 58 (10369 views)

On 10/31/05, Brian Harring <ferringb@gentoo.org> wrote:
> On Mon, Oct 31, 2005 at 04:16:44PM -0800, m h wrote:
> > Kito-
> >
> > Are you leveraging the work done by Haubi documented here:
> > http://gentoo-wiki.com/HOWTO_Use_prefixed_portage_%28in_development%29
>
> Yah, although differs in certain respects;
>
> 1) affix doesn't exist
> 2) bound to a temp EAPI to use for masking non prefix capable ebuilds
> 3) Strict paths. *really* strict.
> 4) by hand reimplementation of the python side of the modifications
> 5) stable based. the patch referenced is 2.1; I (mostly by hand I'm
> afraid) backported the relevant chunks, rewriting what was needed and
> simplifying it down a bit (affix removal fex).
>
> There is common code between them, but right now the prefix patch I've
> been splitting off of 2.0.51-rc4 is the simple cousin of haubi's work,
> round two basically, with a lot of patch monkeying via kito/myself to
> iron the beast out.
>
> > 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.
>
> Should be usable in both cases. Literally, the prefix stable patch is
> chunks of my 2.1 work and haubi's work torn out and integrated into 2.0
> for prototype demonstration. Exempting the AFFIX difference, should
> work in a similar fashion across systems, although haubi's stage0 work
> is a seperate thing.
>

(I don't miss AFFIX...actually I think it's a little confusing).
Thanks for the response Brian. I'm just wondering if your changes are
being tracked anywhere or if there is discussion of this going on
anywhere (in a mailing list perhaps?)? I like to lurk there if
possible...

What bootstrap process do you recommend? (since you aren't using haubi's)

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

ferringb at gentoo

Oct 31, 2005, 6:57 PM

Post #17 of 58 (10358 views)

On Mon, Oct 31, 2005 at 05:20:42PM -0800, m h wrote:
> Thanks for the response Brian. I'm just wondering if your changes are
> being tracked anywhere or if there is discussion of this going on
> anywhere (in a mailing list perhaps?)? I like to lurk there if
> possible...

At the moment, I'm tracking it locally. At some point when basic
portage changes are ironed out, probably will branch it.

No discussion of the underlying portage changes on any mls; pretty
much has been a back and forth interaction between kito and myself.

> What bootstrap process do you recommend? (since you aren't using haubi's)
I'll leave that one to kito to answer...
~harring

Re: The road ahead? [ In reply to ]

Nov 1, 2005, 12:33 AM

Post #18 of 58 (10369 views)

Good to see you posting, Dirk!

dirk.schoenberger@sz-online.de wrote:
>> The Portage take on this would be slightly different, as it will live
>> in its own space, with its own set of GUI accessible .apps,
>> Frameworks, etc. Can you elaborate on "I have to fudge around with
>> PATH variables and other CLI stuff"
>
> In a more Fink inspired way, I think I would have to add at lease a
> PATH=$PATH:/sw/bin resp. the settings for LD_LIBRARY_PATH (or whatever the
> Mac equivalent is)

Ok, but this is of a small concern since you can just add it to your
.bashrc or .tcshrc or whichever .shellrc you use. Just like fink tells
you to source one of their files, we could do the same. Such thing
allows you to make it all accessible without needing lengthy workarounds.

>> and "real MacOSX integration, with App folder and GUI starter elements"
> please?
>
> With this I mean anything which enables me to e.g start X based
> application via the Finder, instead of from a command line. App folder
> would e.g allow me to create a "standalone" application which I can put on
> another machine, without having to re-install the whole Gentoo system. I
> know that this somehow circumvent the whole reason of Gentoo, namely the
> automatic maintenance and update of components and their dependent
> applications.

This is a really cool thought. I quick first impression is that this
should be possible, since on OSX the dylibs can be moved to another
location, or even be in a relative location as in all the .app things.
So perhaps it would indeed be possible to write a script that generates
such app. Practical problems may arise, but I like the idea.

>>> From what I see as a user, the Gentoo packages divide into 4
>>> categories
>>>
>>> 1) packages which integrate nicely into the system (no
>>> dependencies, or
>>> dependencies which are properly provided by MacOS)
>> The problems with this have been outlined numerous times by both
>> users and devs, but to quickly re-hash them: It makes system backups/
>> reinstalls a pain, the deps that are 'properly' provided by apple can
>> and will change without notice, it requires manual mapping of faux-
>> deps via the profiles, a software update or `diskutil
>> repairPermissions /` can render your portage installed files useless,
>> its what keeps the project a laughable novelty to most Darwin/OS X
>> users and developers

But... I do understand you, because I did like it too, when I tried
Gentoo for OSX, that it installs in /usr/bin. However, now I know a bit
more on the real implications of that choice and how fragile and
polluting it is, I prefer to have a nice corner on my system which
Portage doesn't have to share with anyone.

> I am not so long a member of the list, so thanks for the short repetition.
> Is it possible to define some kind of "safe subset" of Apple provided
> packages, i.e something which is less likely to change frequently?

I guess this answer would be no. Apple changes things quite often and
doesn't care about backwards compatibility with devs so much as far as I
can tell. It's their way to innovate and react quickly to the market.
(Which is one of their core competencies.) So basically, I think the
proper way to think is: "don't trust anything you didn't create
yourself". Kito, correct me if I'm wrong here.

>> A USE flag for what exactly? I'm not sure I understand you.
>
> Something like USE="install-local", which installs the package into
> /usr/local instead of /usr.
> In the default console settings this should override Apple provided
> packages, without leading to collisions.

An interesting thought, but why would a user have to do this him or
herself? I'd immediately say that portage would have to do this
automatically when necessary. Why bother a (Mac) user with it? Since
this is a bit complicated, and asks more from Portage (flexible install
location) the current approach is to diss the automatic part and just
always install into an alternative location, since that won't ever
collide with system installed stuff *and* is easier to do in Portage as
far as I have understood the discussions on it.

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

Re: The road ahead? [ In reply to ]

nathan.stocks at gmail

Nov 1, 2005, 9:07 AM

Post #19 of 58 (10362 views)

On 10/31/05, dirk.schoenberger@sz-online.de
<dirk.schoenberger@sz-online.de> wrote:
> Just wanted to put my 2cent into the discussion.
> I suppose I am currently just a pure Gentoo-OSX user, and while I see the
> point of the prefix project, I am not really convinced by it. I like the
> way Gentoo integrates into the system, or at least the part accessible by
> a console.

(Foreward: I'm not trying to be offensive or attack Dirk. Please
read the following as having being written with a 'thoughtful' or
'didactic' tone, because it is)

Hmm. I would have to put my vote firmly in the opposite camp. If
Gentoo can't keep itself separate from OS X, it's useless to me, as I
depend on a fully-functioning OS X system for my day job. Anyone who
needs a working OS X system needs prefixed installs with gentoo-osx.
Path collisions != "integrat[ing] into the system".

> I see this as an advantage above e.g. Fink, with its own namespace. The
> namespace variant implies that I have to fudge around with PATH variables
> and other CLI stuff, in order to get the apps working. I still have no
> real MacOSX integration, with App folder and GUI starter elements (which
> would be my biggest feature request)

I see not trashing the existing system software as far more important
than the minor configuration of your path. This is Gentoo! What "App
folder" are you expecting? KDE menus, Gnome menus, etc. are basically
fancy widgets that execute CLI commands when you click on them. If
you need something to click on for your own sanity, the logical thing
for you to do would be to create some scripts in /Applications that
call the X apps you use when you click on them, assuming you got the X
apps installed in the first place. I wouldn't be surprised if someone
came up with a fink-commander-like project for OS X (to install and
run stuff) if the prefixed-installs-hurdle ever gets passed.

> From what I see as a user, the Gentoo packages divide into 4 categories
>
> 1) packages which integrate nicely into the system (no dependencies, or
> dependencies which are properly provided by MacOS)

No collisions and no dependencies? No reason to wait for gentoo-osx then.

> 2) packages which clash with MacOS provided packages, things like python
> or automake spring to mind

And bash, ls, grep, emacs, vi, vim, gcc, perl, python, tcl/tk, apache,
etc. etc. etc.
I would guess this is a _lot_ of packages, including most of the stuff
that just having a gentoo system depends on.

> 3) packages which depend on 2)

This wold be the rest of the packages.

> 4) misc packages which are otherwise problematic. This means most of the
> package.masked packages, where I cannot really speak about.

Not really a separate category. Any of the above can belong to your
category 4 as well.

> The biggest problem is obiously the packages in 2)

Which prefixed installs will solve. When portage fully supports
prefixed installs, then:
(1) A base system gets created by devs by whatever means (hopefully
the only step with mandatory dependencies on Apple tools)
(2) Regular users install the prefix-enabled base system into a prefix
(and add $PREFIX/bin, $PREFIX/sbin, etc. to .bashrc)
(3) 'emerge mypackage' uses the gentoo system in $PREFIX to build
'mypackage' and install in into
$PREFIX/regular/gentoo/path/for/the/package
(4) USERS REJOICE!
(5) At this point, I'm sure someone will start a 'fink-commander'-like
project for people who aren't comfortable with the command-line

> My private idea in order to emerge packages in 3) would currently be to
> manually install the needed packages in places like /usr/local (instead of
> Gentoos /usr) and put these packages into package.provided. It would be
> really nice if I could use this way while still being able to use the
> emerge functionaltiy. Perhaps this could be handled by a special USE flag?

Manually "install" packages whose dependencies won't install? I think
you have missed the concept that the dependencies are necessary to
both compile and run the package.

Anyway, not trying to be disagreeable or mean--no offense meant to
Dirk in any way.

I'm excited to hear kito/ferringb's news about prefixed install
progress. I've been a Gentoo user for 3 years and currently have over
a dozen rack-mounted Gentoo Linux (x86) servers (and more coming every
month). I've got four other developers at my work and myself using
100% Apple hardware on the desktop (powerbooks mostly), and soon 100%
Gentoo Linux on the servers. We're all currently using fink and
darwinports for our OSS currently--just waiting for prefixed
installs...

Man, that took too long. I had better get to work. :-)

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Nov 1, 2005, 9:28 AM

Post #20 of 58 (10371 views)

On Nov 1, 2005, at 10:07 AM, Nathan wrote:

> When portage fully supports
> prefixed installs, then:
> (1) A base system gets created by devs by whatever means (hopefully
> the only step with mandatory dependencies on Apple tools)

Well, we are starting off with no concept of package.provided, i.e.
we won't be lying to portage about too much like we have in the past,
so there will be no hard dependency on Xcode.

> (2) Regular users install the prefix-enabled base system into a prefix
> (and add $PREFIX/bin, $PREFIX/sbin, etc. to .bashrc)

I was thinking either they just open a shell and `source ${PREFIX}/
etc/profile` or they can set their default shell to ${PREFIX}/bin/
{bash,csh,zsh,whatever} which will already have a sane env with the
prefixed paths.

> (3) 'emerge mypackage' uses the gentoo system in $PREFIX to build
> 'mypackage' and install in into
> $PREFIX/regular/gentoo/path/for/the/package

Thats the idea ;) Keep in mind, binary packages are a must, so there
will be a default prefix that has to be used for both the stage
tarballs and the binpkgs. It will still be possible for a user to
bootstrap to a custom prefix, but I think that we shouldn't really
support anything other than the default.

> (4) USERS REJOICE!

Amen.

> (5) At this point, I'm sure someone will start a 'fink-commander'-like
> project for people who aren't comfortable with the command-line

Yeah, something written in python would seem logical....

--Kito

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

nathan.stocks at gmail

Nov 1, 2005, 9:55 AM

Post #21 of 58 (10355 views)

dirk.schoenberger at sz-online

On 11/1/05, Kito <kito@gentoo.org> wrote:
> > (2) Regular users install the prefix-enabled base system into a prefix
> > (and add $PREFIX/bin, $PREFIX/sbin, etc. to .bashrc)
>
> I was thinking either they just open a shell and `source ${PREFIX}/
> etc/profile` or they can set their default shell to ${PREFIX}/bin/
> {bash,csh,zsh,whatever} which will already have a sane env with the
> prefixed paths.

'source ${PREFIX}/etc/profile' <-- Good thinking.

> > (3) 'emerge mypackage' uses the gentoo system in $PREFIX to build
> > 'mypackage' and install in into
> > $PREFIX/regular/gentoo/path/for/the/package
>
> Thats the idea ;) Keep in mind, binary packages are a must, so there
> will be a default prefix that has to be used for both the stage
> tarballs and the binpkgs. It will still be possible for a user to
> bootstrap to a custom prefix, but I think that we shouldn't really
> support anything other than the default.

Sounds good to me. Those picky enough to want some different prefix
could also play with symlinks.

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Nov 1, 2005, 9:57 AM

Post #22 of 58 (10361 views)

>> I see this as an advantage above e.g. Fink, with its own namespace. The
>> namespace variant implies that I have to fudge around with PATH
>> variables
>> and other CLI stuff, in order to get the apps working. I still have no
>> real MacOSX integration, with App folder and GUI starter elements (which
>> would be my biggest feature request)
>
> I see not trashing the existing system software as far more important
> than the minor configuration of your path. This is Gentoo! What "App
> folder" are you expecting? KDE menus, Gnome menus, etc. are basically
> fancy widgets that execute CLI commands when you click on them.

Sorry, but this attitude firmly belong into the "a GUI is just a frontend
to the CLI" camp, where I don't really subscribe too. A CLI has its place,
but a GUI does so, too, and both are not dependent upon.
KDE / GNOME .desktop entries doesn't really compare to Apple's app
folders, because .desktop entries are really just start scripts. An app
folder contains starting scripts and the related resources / libraries in
an all in one package. The idea is that you can copy an app folder around
in your local file system or to another file system (thing .dmg here),
while the application still remains runnable. So you have to include any
library, beside the Apple provided ones.

> If you need something to click on for your own sanity, the logical thing
> for you to do would be to create some scripts in /Applications that
> call the X apps you use when you click on them, assuming you got the X
> apps installed in the first place. I wouldn't be surprised if someone
> came up with a fink-commander-like project for OS X (to install and
> run stuff) if the prefixed-installs-hurdle ever gets passed.

From what I see, fink-commander is a frontend to fink, i.e. to the
packages, not to the actual applications. Last time I checked, a gentoo or
fink package has no concept about which are the actual executables.

>
>> From what I see as a user, the Gentoo packages divide into 4 categories
>>
>> 1) packages which integrate nicely into the system (no dependencies, or
>> dependencies which are properly provided by MacOS)
>
> No collisions and no dependencies? No reason to wait for gentoo-osx then.

No complicated dependencies. So this is the easiest part, where I still
like to have Gentoo's safety net which keeps knowledge about what files
belong to which package. This allows for clean uninstall, at least what
concerns removing files. I am not quite sure about Fink style install and
uninstall scripts.

>
>> 2) packages which clash with MacOS provided packages, things like python
>> or automake spring to mind
>
> And bash, ls, grep, emacs, vi, vim, gcc, perl, python, tcl/tk, apache,
> etc. etc. etc.

python and automake are the cases which really annoy me, but naturally you
are correct about the other packages, too. If possible I would like to use
an Apple provided gcc, so this package is disputable.

> I would guess this is a _lot_ of packages, including most of the stuff
> that just having a gentoo system depends on.
>
>> 3) packages which depend on 2)
>
> This wold be the rest of the packages.

Yes and no. For me 3) are the packages, which I would like to emerge, but
I cannot because of missing 2) packages. 4) are packages which are still
considered unstable / problematic by the package maintainers, so that I
don't want to toy around with, yet.

>> The biggest problem is obiously the packages in 2)
>
> Which prefixed installs will solve. When portage fully supports
> prefixed installs, then:
> (1) A base system gets created by devs by whatever means (hopefully
> the only step with mandatory dependencies on Apple tools)
> (2) Regular users install the prefix-enabled base system into a prefix
> (and add $PREFIX/bin, $PREFIX/sbin, etc. to .bashrc)
> (3) 'emerge mypackage' uses the gentoo system in $PREFIX to build
> 'mypackage' and install in into
> $PREFIX/regular/gentoo/path/for/the/package
> (4) USERS REJOICE!
> (5) At this point, I'm sure someone will start a 'fink-commander'-like
> project for people who aren't comfortable with the command-line
>

Maybe I am just not in possession of all the facts, so I will stop
expressing an opinion about this as long as there are no visible results.

> Manually "install" packages whose dependencies won't install? I think
> you have missed the concept that the dependencies are necessary to
> both compile and run the package.
>

No. manually installing the packages which are needed to emerge the actual
wanted packages. The latter are still emerged via Gentoo.

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

Re: The road ahead? [ In reply to ]

Nov 1, 2005, 10:17 AM

Post #23 of 58 (10362 views)

Kito wrote:
>> (5) At this point, I'm sure someone will start a 'fink-commander'-like
>> project for people who aren't comfortable with the command-line
>
> Yeah, something written in python would seem logical....

Eh... pywhat?

I'd expect a very groovy native cocoa app that bypasses the clumsyness
of Fink commander by a few orders of a magnitude. I *DEMAND* such
application to be written... eh... any volunteers?!? :)

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

Re: The road ahead? [ In reply to ]

Nov 1, 2005, 10:26 AM

Post #24 of 58 (10373 views)

dirk.schoenberger@sz-online.de wrote:
> Sorry, but this attitude firmly belong into the "a GUI is just a frontend
> to the CLI" camp, where I don't really subscribe too. A CLI has its place,
> but a GUI does so, too, and both are not dependent upon.
> KDE / GNOME .desktop entries doesn't really compare to Apple's app
> folders, because .desktop entries are really just start scripts. An app
> folder contains starting scripts and the related resources / libraries in
> an all in one package. The idea is that you can copy an app folder around
> in your local file system or to another file system (thing .dmg here),
> while the application still remains runnable. So you have to include any
> library, beside the Apple provided ones.

I see your point, but I think it's a bit unrelated to Gentoo. It might
however be easier to accomplish with Gentoo because it compiles from
sources and has more control on how a package is built. Ideally one
could do "ebuild myapp-1.0.ebuild osxapp" or something, just like
"ebuild myapp-1.0.ebuild rpm" is there. (Or was envisioned.)

>>> 1) packages which integrate nicely into the system (no dependencies, or
>>> dependencies which are properly provided by MacOS)
>> No collisions and no dependencies? No reason to wait for gentoo-osx then.
>
> No complicated dependencies. So this is the easiest part, where I still
> like to have Gentoo's safety net which keeps knowledge about what files
> belong to which package. This allows for clean uninstall, at least what
> concerns removing files. I am not quite sure about Fink style install and
> uninstall scripts.

Uninstalling fink is "rm -R /sw", uninstalling a separate package...
well, must be possible, though I cannot remember having it done myself.

>>> 2) packages which clash with MacOS provided packages, things like python
>>> or automake spring to mind
>> And bash, ls, grep, emacs, vi, vim, gcc, perl, python, tcl/tk, apache,
>> etc. etc. etc.
>
> python and automake are the cases which really annoy me, but naturally you
> are correct about the other packages, too. If possible I would like to use
> an Apple provided gcc, so this package is disputable.

Yes, me too, and especially the Apple linker! (ld) But maybe Kito knows
whether this linker can also be installed if the source is available.

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

Re: The road ahead? [ In reply to ]

nathan.stocks at gmail

Nov 1, 2005, 11:08 AM

Post #25 of 58 (10370 views)