[gentoo-osx] The road ahead?

[gentoo-osx] The road ahead?

[dirk.schoenberger]

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: [gentoo-osx] The road ahead?

[Kito]

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: [gentoo-osx] The road ahead?

[dirk.schoenberger]

>>
>> 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: [gentoo-osx] The road ahead?

[Grobian]

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: [gentoo-osx] The road ahead?

[Nathan]

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: [gentoo-osx] The road ahead?

[Kito]

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: [gentoo-osx] The road ahead?

[Nathan]

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: [gentoo-osx] The road ahead?

[Grobian]

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: [gentoo-osx] The road ahead?

[Nathan]

On 11/1/05, Grobian <grobian@gentoo.org> wrote:
> 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?!? :)

Hehe.  I volunteer Apple.  They're good at Cocoa development.  iGentoo!

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[m h]

There's also pyobjc which allows integration of python and cocoa....

On 11/1/05, Nathan <nathan.stocks@gmail.com> wrote:
> On 11/1/05, Grobian <grobian@gentoo.org> wrote:
> > 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?!? :)
>
> Hehe.  I volunteer Apple.  They're good at Cocoa development.  iGentoo!
>
> --
> gentoo-osx@gentoo.org mailing list
>
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

Well, I envisioned a some sort of 'fast' application which doesn't 
needlessly eat gigabytes of memory and also looks like a native Mac 
application.

m h wrote:
> There's also pyobjc which allows integration of python and cocoa....


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

Re: [gentoo-osx] The road ahead?

[m h]

What would make a objective c program any faster than python in this
case?  It doesn't seem like it would be cpu bound.
If you use pyobjc you get a "native" gui (and you can use py2app to
create a "native" application), you just get to program parts of it in
a nicer language.

On 11/1/05, Grobian <grobian@gentoo.org> wrote:
> Well, I envisioned a some sort of 'fast' application which doesn't
> needlessly eat gigabytes of memory and also looks like a native Mac
> application.
>
> m h wrote:
> > There's also pyobjc which allows integration of python and cocoa....
>
>
> --
> Fabian Groffen
> Gentoo for Mac OS X Project -- Interim Lead
> --
> gentoo-osx@gentoo.org mailing list
>
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

In general, I'm not impressed by the performance of Python.  I'm not 
impressed by the language itself either, but that's just taste.  If 
you'd create such program, I'd be happy with it too ;)


m h wrote:
> What would make a objective c program any faster than python in this
> case?  It doesn't seem like it would be cpu bound.
> If you use pyobjc you get a "native" gui (and you can use py2app to
> create a "native" application), you just get to program parts of it in
> a nicer language.
> 
> On 11/1/05, Grobian <grobian@gentoo.org> wrote:
>> Well, I envisioned a some sort of 'fast' application which doesn't
>> needlessly eat gigabytes of memory and also looks like a native Mac
>> application.
>>
>> m h wrote:
>>> There's also pyobjc which allows integration of python and cocoa....
>>
>> --
>> Fabian Groffen
>> Gentoo for Mac OS X Project -- Interim Lead
>> --
>> gentoo-osx@gentoo.org mailing list
>>
>>
> 

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

Re: [gentoo-osx] The road ahead?

[m h]

There are some efforts underway (pypy) to improve the performance of
python (which may or may not pan out).  Sorry, I didn't intend to say
that you should only program in python (even though I prefer to when
able).  I'm quite aware that many people find python annoying.  Just
thought that it might make sense in this case since portage is written
in python, it should be pretty easy to get a frontend cleanly
integrated using it.

I'm not an objc nor cocoa person so I can't really comment on that
front (read portions of the oreilly cocoa book and wasn't motivated to
continue ;( ).  Also as the only Mac I have access to is one at work,
I don't know that I'll be writing any frontend for osx.  My interest
here is in the generalized PREFIX install.

On 11/1/05, Grobian <grobian@gentoo.org> wrote:
> In general, I'm not impressed by the performance of Python.  I'm not
> impressed by the language itself either, but that's just taste.  If
> you'd create such program, I'd be happy with it too ;)
>
>
> m h wrote:
> > What would make a objective c program any faster than python in this
> > case?  It doesn't seem like it would be cpu bound.
> > If you use pyobjc you get a "native" gui (and you can use py2app to
> > create a "native" application), you just get to program parts of it in
> > a nicer language.
> >
> > On 11/1/05, Grobian <grobian@gentoo.org> wrote:
> >> Well, I envisioned a some sort of 'fast' application which doesn't
> >> needlessly eat gigabytes of memory and also looks like a native Mac
> >> application.
> >>
> >> m h wrote:
> >>> There's also pyobjc which allows integration of python and cocoa....
> >>
> >> --
> >> Fabian Groffen
> >> Gentoo for Mac OS X Project -- Interim Lead
> >> --
> >> gentoo-osx@gentoo.org mailing list
> >>
> >>
> >
>
> --
> Fabian Groffen
> Gentoo for Mac OS X Project -- Interim Lead
> --
> gentoo-osx@gentoo.org mailing list
>
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Nathan]

On 11/1/05, m h <sesquile@gmail.com> wrote:
> There's also pyobjc which allows integration of python and cocoa....

That's true!  I wanted to look into that a long time ago, but not
knowing python nor cocoa at the time, I decided not to.  I'm now
decently fluent in python.  Do you happen to know how much
Cocoa/Object-oriented C you have to know to use pyobjc?

I've been itching to create something with a GUI for a decade
now...just  for fun.

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[dirk.schoenberger]

>> 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: [gentoo-osx] The road ahead?

[Grobian]

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: [gentoo-osx] The road ahead?

[Nathan]

On 11/1/05, dirk.schoenberger@sz-online.de
<dirk.schoenberger@sz-online.de> wrote:
>
> >> 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.

Two problems with your logic:

1) The affirmation that all the libraries every .app needs are
included in .app folders is false.  Check out /Library and
/usr/lib--you will find that they are not even close to empty.  .app's
depend heavily on having a relatively stable OS X system out there to
support it.  Try dragging Mail.app from a Tiger installation onto a
Jaguar installation and see if it works.

2) I think you dragged out the "GUI is/isn't just a frontend to the
CLI" issue to try to argue for app-like organization of files. 
They're not the same issue.  Let's face it: one of the main reason's
portage exists is to easily manage compiling/installing packages in a
nice orderly way without going upstream to all the projects you are
using and somehow forcing them all to recode their projects so they
work in an app-like organization.  The .app concept is great, but
you'll be on your own to go to every separate pre-existing project and
convince them to port it so that it install itself into .app
organization and runs.  The whole .app thing has to be addressed by
the people who code the applications, and can't be imposed by portage.
 Even assuming you DID get portage to force things into .app
structures and work perfectly, the moment you dragged it to another
system without the exact same versions of compiled gentoo libraries,
you're hosed.

Don't get me wrong, I think the whole app idea is awesome.  .app's can
and have been created for OSS (Carbon Emacs, for example), but if
you're going to go to all the trouble to create a real .app, there's
no need for a special package manager (portage) just to copy it into
your /Applications folder.  Creating an Apple-style app seems to be
painful enough that most OSS projects will fork into separate regular
and app-oriented projects rather than support the .app structure in
the main line.

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

Splitting hairs.  If you make it, then have it do what you want it to do.

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

You are free to use Apple gcc -- that's what it's on your system for. 
However, gentoo stuff specifically depends on the features, quirks,
and even bugs in its own supported toolchain, including gcc.  Once
there is a "stable, working" version of gentoo-osx, don't expect a lot
of sympathy from gentoo devs if you're not going to use standard
gentoo toolchain.  I certainly wouldn't object if a way was found to
use any of Apple's tools, especially if they are better in some way,
but I'm not going to hold my breath.

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

Opinions are fine.  I'm trying to clarify facts as much as I can and
as far as I understand them.  The more gentoo users/devs/supporters,
the better, because then I will have an easier time getting 'my stuff'
to work. :-)

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

Portage exists to automate (and customize) manual installs.  If you
can find a way to manually install it correctly, and the ebuild in
portage can't, then the solution is to fix the ebuild so that it works
for everyone.

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[dirk.schoenberger]

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

> Two problems with your logic:

> 1) The affirmation that all the libraries every .app needs are
> included in .app folders is false.  Check out /Library and
> /usr/lib--you will find that they are not even close to empty.  .app's
> depend heavily on having a relatively stable OS X system out there to
> support it.  Try dragging Mail.app from a Tiger installation onto a
> Jaguar installation and see if it works.

You are right about that not everything is included. SO I still think
there must exist a set of libraries which are shared across several MacOS
version.
The question is if these set is somewhere documented, and how reliable
this portability is.
But it still is possible to create .app folders which run on several
MacOSX versions. Apple Mail may or maybe not a shining example for this.

> 2) I think you dragged out the "GUI is/isn't just a frontend to the
> CLI" issue to try to argue for app-like organization of files.
> They're not the same issue.  Let's face it: one of the main reason's
> portage exists is to easily manage compiling/installing packages in a
> nice orderly way without going upstream to all the projects you are
> using and somehow forcing them all to recode their projects so they
> work in an app-like organization.

- Yes, both issues are separate
- No, I don't think any Gentoo package is suited for an app folder.
- Yes, normally I am fine with a global namespace, too. However, there exist
  reasons that I would like to create an .app folder for special
applications.
- In fact the "GUI is/isn't just a frontend to the CLI" argument I see
more as a
  problem for the prefixed approach. If I am able to start an application
from
  the GUI / Finder, I cannot be sure which .{shell}rc is executed, and so
which
  non-standard places are accessible to an application starter. When I try to
  start an application which tries to load its libraries from e.g.
/sw/lib, I am not
  quite sure about the results
- From what I understood, .app folder don't really need much work from the
  upstream developers. It should be sufficient to specify the correct
paths, at
  least if a proper build tool is used. I am not quite sure, but I think .app
  folders mostly work because of linker magic, i.e.  some conventions about
  where libraries are places relatively to the app folder root.

>  Even assuming you DID get portage to force things into .app
> structures and work perfectly, the moment you dragged it to another
> system without the exact same versions of compiled gentoo libraries,
> you're hosed.

I thought that was the reason for some magic concept like source and
especially binary compatibility for a given library?

> Don't get me wrong, I think the whole app idea is awesome.  .app's can
> and have been created for OSS (Carbon Emacs, for example), but if
> you're going to go to all the trouble to create a real .app, there's
> no need for a special package manager (portage) just to copy it into
> your /Applications folder.

I think the use cases are different. A pure portage based system is fine
as long as you have a running Gentoo system, or you are willing to take
the plunge.
An app folder is fine if you want to deploy an emerged application to a
system which has no Gentoo running (an example would be the Mac system of
my parents. I would really like being able to show off some recent version
of, say, Abiword compiled for MacOS, without having to download a special
version from the Abiword developer's site)

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

> Splitting hairs.  If you make it, then have it do what you want it to do.

I don't think such a system which automatically creates startable
applications, would be possible right now in Gentoo. There is too much
missing metadata in the Gentoo system for such a task.

> You are free to use Apple gcc -- that's what it's on your system for.
> However, gentoo stuff specifically depends on the features, quirks,
> and even bugs in its own supported toolchain, including gcc.  Once
> there is a "stable, working" version of gentoo-osx, don't expect a lot
> of sympathy from gentoo devs if you're not going to use standard
> gentoo toolchain.  I certainly wouldn't object if a way was found to
> use any of Apple's tools, especially if they are better in some way,
> but I'm not going to hold my breath.

While I may agree about special Apple tools like Xcode (vs Gentoo
./configure/make/make install), I don't think this applies for the actual
C compiler. I think even in the stock Gentoo toolchain there is the
distinction between gcc-3 and gcc-4, where each individual Gentoo
installation decides which version too use. Apple's gcc-4 is (or should
be?) just another option for a C compiler, at least as long as no Apple
specific features are used (think e.g. support for ObjectiveC++ support)

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

> Portage exists to automate (and customize) manual installs.  If you
> can find a way to manually install it correctly, and the ebuild in
> portage can't, then the solution is to fix the ebuild so that it works
> for everyone.

As long as I can coerce Gentoo to actually emerge a package, everything is
fine. The problems start if this is not possible (for a variety of
reasons)

Regards
Dirk






-- 
gentoo-osx@gentoo.org mailing list

[gentoo-osx] The road ahead?

[Grobian]

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.

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.
   - Although I have seen signals that we're close to something like
     this (kudos to Kito and Brian) 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.

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.


[1] ciaranm@gentoo.org in gentoo-alt@gentoo.org (not archived on gmane)
[2] http://bugs.gentoo.org/show_bug.cgi?id=108029

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

Re: [gentoo-osx] The road ahead?

[Stroller]

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: [gentoo-osx] The road ahead?

[Lina Pezzella]

-----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: [gentoo-osx] The road ahead?

[Grobian]

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: [gentoo-osx] The road ahead?

[Kito]

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

> Since it "is silly if you want things to work before several years  
> off"
> [1], perhaps it's not that useful to discuss this issue.  However, we
> can all dream, can't we, so let's just do it(tm).
>
> I will try to carve a few roads in the sand in this mail that should
> somehow reflect what I think the things to discuss are, if we really
> want to get moving towards our holy grail.  Considering [1], this  
> might
> be all useless afterward, but ok.
>
> My personal targets for this project are as follows:
> 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo family.
> 2. Get a prefixed install to make Gentoo for OSX comparative to  
> Fink and
>    Darwin Ports, and quality wise go beyond.

Why (2) is not first on everyones priority list, I really don't  
understand. If we can do (2) in a reasonably sane fashion, (1) will  
'just happen'.

>
> Both two targets require some extra explanation.
> 1. Gentoo for OSX functions as "black sheep" of the Gentoo family.  In
>    that way we put a spell on not only ourselves, but also on the
>    Gentoo/Alt project -- which is a good candidate for the second  
> black
>    sheep.  It may be just that some people don't like the smell of non
>    GNU/Linux stuff, but there are also constructive comments which
>    cannot be denied.
>    - My current stategy is to just show some goodwill, by for instance
>      reacting swift and accurate to security bugs, as my impression is
>      that those have been ignored in the past.  But not only securty
>      bugs, all bugs where we get involved I try to react within
>      reasonable time, just to show we care.  Well I do.  Of course any
>      support in this gets a warm welcome from me.
>    - In cooperation with others (mostly vapier) I try to reduce the
>      ebuild "spam" caused by ppc-macos.  An example is the big
>      anti conditional bug [2] which unfortunately hasn't got much of
>      my attention yet.  The idea is simple: make unconditional stuff
>      just to ease maintenance and keep ebuilds slim and pure.
> 2. A prefixed install for me means having a way to install into
>    /Library/Gentoo, /Gentoo, /Users/Library/Gentoo or wherever.  I  
> don't
>    really care about the location, and a system wide install would be
>    fine with me too.  I envision that a touch discussion on variable
>    prefixes, or homedir prefixes and whatever will follow if not yet
>    have been on the portage channels.  What I would like to see is  
> that
>    we can play with it, maybe not in its ideal state, but those
>    improvements can be made while we're playing.

My impression is everyone in the OS X team feels this is something  
thats going to get immaculately implemented by the portage gods,  
leaving us to reap the benefits.... not likely... If we don't do the  
work, no one will. I've been trying for months to no avail to get  
others involved so we can start 'playing with it'. Can lead a horse  
to water but can't make him drink I suppose...

>    - Although I have seen signals that we're close to something like
>      this (kudos to Kito and Brian)

I have a self-hosting toolchain working in a prefix right now. Tons  
of bugs, tons of things not implemented yet, etc. etc. but its a  
solid start. Keep in mind, this should only be considered a proof-of- 
concept, mainly to help determine the requirements of the ebuilds  
when working in a prefixed environment.

My rough plan is to squash a few of the major bugs left (collision- 
protect and binpkgs primarily), with brians help roll a new patch  
against current stable portage(using rc4 currently), check my overlay  
into the alt svn module, create a "developers preview" install pkg,  
and then continue adding ebuilds to the EAPI=1 overlay, adding  
features/bug squashing as we go. Once the overlay is in a fairly  
workable state, we can start/continue the beloved GLEP/Flaming  
process we all know and love.

Brian has better insight than I on the long-term roadmap, so  
hopefully he'll chime in here, but my guess is the very very earliest  
we could see prefixed support in mainline would be around the time of  
saviours(3.0) official release... but in the meantime there is by no  
means any shortage of work to be done...

All that being said, the more people working towards this same goal,  
the higher the probability of its success and eventual adoption by  
Gentoo proper.

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

Again, I think that once a product exists that is actually useful,  
both devs and users a like will start showing up...bit of a chicken/ 
egg situation I know, but this is opensource, without a strong  
userbase, we won't ever have a strong dev team.

>
> To conclude a short note on various flavours of the project, such as
> progressive and darwin.  I am not interested in those myself.  My main
> focus is on the 'consumer product', which should be the mainline
> product, or the collision-protect profiles as they are called now.   
> The
> fact that I am not interested (yet) into these profiles, does not  
> mean I
> will never support them.  I would just like to focus on getting the
> mainline (normal users) product going, then if people have a personal
> target to create a progressive profile for instance, I will not stop
> such development -- not even wondering on how I would be able to  
> stop it
> anyway.  I consider one of my personal wishes for a 64-bit install to
> be a profile that should walk the same path like a progressive  
> profile:
> it should wait till there is a working mainline product.

To follow that logic, why are we continuing to mark things ~ppc-macos  
when we don't even have a working a mainline product? I look at the  
progressive profile about the same as you look at mass keywording for  
all of dirks bug reports..."Its not extremely useful right now, but  
the work will have to be done at some point, so why not now?"

Building a prefixed stage1 went extremely quickly because most of the  
base-system packages had already been ported to OS X via my work with  
the base-system people(ok, mainly just spanky ;) on the progressive  
profile(perl,bash,coreutils,gcc- 
apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, etc. etc.).   
This attitude of 'we only support the consumer product' is a good  
outward goal, but is also what IMHO contributed to the half-assed  
nature of the current collision-protect profiles...i.e. "We have a  
very short sighted implementation, that is a maintenance nightmare,  
requires very heavy modifications to the tree, and has virtually 0  
appeal to both devs and users, but lets keep working hard and try to  
get gaim and x-chat keyworded ppc-macos because its what users want."

What I'm saying is, darwin and progressive provide a testbed for the  
bottom-up approach that we should have been taking from the beginning.

--Kito
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

Kito wrote:
>> My personal targets for this project are as follows:
>> 1. Make Gentoo for OSX an acceptable sub-project of the Gentoo family.
>> 2. Get a prefixed install to make Gentoo for OSX comparative to Fink and
>>    Darwin Ports, and quality wise go beyond.
> 
> Why (2) is not first on everyones priority list, I really don't 
> understand. If we can do (2) in a reasonably sane fashion, (1) will 
> 'just happen'.

Well.  Not that I don't agree with you, but I don't have as much of a 
good indication how far away we are from the holy grail.  Hence, in the 
meanwhile while *I* have to wait for the long awaited gift from above, I 
try to fix those things that are possible without the prefix.  However, 
if I would have to chose between a prefixed portage next week, or 
getting a lot of ebuilds sane within a week, I wouldn't hestitate to go 
for the first one.  Hope this calms you down a bit ;)  I just reasoned 
from my own perspective as in what *I can* do.  I have limitations also.

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

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

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

Would you like to lead this sub-project, define roles, tasks and roll 
out a todo list or some minimalistic readme, so people can get involved 
and perhaps start wondering around in the code?
I just say this because I think you are the one with the knowledge here. 
  Feel free to post regular updates of the ongoing work, bottle-necks, 
issues and where work is needed to the list.

> Again, I think that once a product exists that is actually useful, both 
> devs and users a like will start showing up...bit of a chicken/egg 
> situation I know, but this is opensource, without a strong userbase, we 
> won't ever have a strong dev team.

It is of a not so big concern of me now.  It is on the road ahead.  In 
the end it's much easier to craft the very kernel of our project with a 
small team, IMHO.

>> To conclude a short note on various flavours of the project, such as
>> progressive and darwin.  I am not interested in those myself.  My main
>> focus is on the 'consumer product', which should be the mainline
>> product, or the collision-protect profiles as they are called now.  The
>> fact that I am not interested (yet) into these profiles, does not mean I
>> will never support them.  I would just like to focus on getting the
>> mainline (normal users) product going, then if people have a personal
>> target to create a progressive profile for instance, I will not stop
>> such development -- not even wondering on how I would be able to stop it
>> anyway.  I consider one of my personal wishes for a 64-bit install to
>> be a profile that should walk the same path like a progressive profile:
>> it should wait till there is a working mainline product.
> 
> To follow that logic, why are we continuing to mark things ~ppc-macos 
> when we don't even have a working a mainline product? I look at the 
> progressive profile about the same as you look at mass keywording for 
> all of dirks bug reports..."Its not extremely useful right now, but the 
> work will have to be done at some point, so why not now?"

Because I still don't understand the idea of progressive, and I do 
understand myself a bit sometimes.  So for me, progressive is a skim 
that exists in bugzilla, but every bug assigned to progressive is 
basically dead.  ~ppc-macos is simply the testing side of the mainline 
product we have.

> Building a prefixed stage1 went extremely quickly because most of the 
> base-system packages had already been ported to OS X via my work with 
> the base-system people(ok, mainly just spanky ;) on the progressive 
> profile(perl,bash,coreutils,gcc-apple,flex,bison,python,auto*,texinfo,zlib,bzip2,rsync, 
> etc. etc.).  This attitude of 'we only support the consumer product' is 
> a good outward goal, but is also what IMHO contributed to the half-assed 
> nature of the current collision-protect profiles...i.e. "We have a very 
> short sighted implementation, that is a maintenance nightmare, requires 
> very heavy modifications to the tree, and has virtually 0 appeal to both 
> devs and users, but lets keep working hard and try to get gaim and 
> x-chat keyworded ppc-macos because its what users want."

Yeah, ok.  But do you have a better solution?  Its not *my* fault that 
we're in the mess we're in.  I just try to use pure management logic at 
the moment.  Might be short sighted... but on the other hand, I'm not 
going to ask someone to wait a few months or maybe a year with going 
systematically through portage and check everything if it compiles or 
not.  I'm just very happy that such person wants to go through that horror.

> What I'm saying is, darwin and progressive provide a testbed for the 
> bottom-up approach that we should have been taking from the beginning.

Don't blame me for what's not my fault.  It has *absolutely* no use to 
keep on telling what is wrong now at the moment.  The only way out of 
there is what ciarmn would like to see the best: remove the full 
ppc-macos keyword from the tree.  Then what ciarmn wouldn't like so much 
to see is that you can start all over from scratch in an overlay.

Stressing the importance of progressive or darwin is ok.  I won't deny 
you are right, but as a project in itself it is not of relevance.  It is 
implicit for me that you need the clean compiles in the prefix, but when 
you have that, I simply don't see what a progressive profile would bring 
in advantages.  The mainline profile of prefixed installs is more or 
less what "-collision-protect" is now.  From a user perspective.

Maybe I think way to simple for you, or with a too commercial vision.  I 
just think it's better to move, instead of sink away deeper in the sand.


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

Re: [gentoo-osx] The road ahead?

[Kito]

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

Re: [gentoo-osx] The road ahead?

[Grobian]

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: [gentoo-osx] The road ahead?

[Lina Pezzella]

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


On Oct 31, 2005, at 2:34 PM, Grobian 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?

Personally I think we're too small of a team to necessitate sub- 
projects like this. This being said, I don't see any problem  
deferring to kito on this issue, since he is the one with the  
knowledge on this subject.

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

Kito - I would love to get involved with the prefix work. Further, I  
completely agree with you that this is a priority. The reasons I  
haven't to date are as follows:

(1) limited time due to college + ongoing interviews
(2) no idea of how to get involved with it.
(3) the feeling that I would not be particularly useful in this area.

This being said, if you can roll out a todo list and a minimal readme  
for getting this type of setup running, I would love to be involved  
with it. I warn you ahead of time that my python knowledge is non- 
existant.

- --Lina Pezzella
Gentoo Developer



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

iD8DBQFDZ/ATNJ9STR9DbYERAmeTAKC/PGdDq4nkbM2soUHCuxAXedXHfACgkcx8
d0NJUAadzFcpsR5Kv+0N+Jo=
=gOX9
-----END PGP SIGNATURE-----
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 4:45 PM, Lina Pezzella wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Oct 31, 2005, at 2:34 PM, Grobian 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?
>
> Personally I think we're too small of a team to necessitate sub- 
> projects like this. This being said, I don't see any problem  
> deferring to kito on this issue, since he is the one with the  
> knowledge on this subject.

Pretty much my feeling, but if it were needed/wanted, it would be an  
alt sub-project as it reaches further than just os x.

>
>> 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.
>
> Kito - I would love to get involved with the prefix work. Further,  
> I completely agree with you that this is a priority. The reasons I  
> haven't to date are as follows:
>
> (1) limited time due to college + ongoing interviews
> (2) no idea of how to get involved with it.
> (3) the feeling that I would not be particularly useful in this area.
>
> This being said, if you can roll out a todo list and a minimal  
> readme for getting this type of setup running, I would love to be  
> involved with it.

Excellent. I'm finishing up the last few system packages right now 
(cctools and gcc mainly), then I want to get the 2 major bugs fixed,  
collision-protect(many false positives) and binpkgs (getting key  
errors on pkgmerge). After that I'll bug brian to help me roll a new  
patch against current portage (rc7 at the time of writing), post an  
install pkg and stage1 for darwin/osx, and get the overlay in the svn  
module. Oh..and make a page on the wiki.

> I warn you ahead of time that my python knowledge is non-existant.

No worries, theres lots to do on the bash/ebuild side as well. The  
more ebuilds we can get in the overlay the better. Also need help  
testing on other archs and in a traditional non-prefixed install to  
catch any regressions.

--Kito

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

Kito wrote:
> On Nov 1, 2005, at 4:45 PM, Lina Pezzella wrote:
>> On Oct 31, 2005, at 2:34 PM, Grobian 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?
>>
>> Personally I think we're too small of a team to necessitate 
>> sub-projects like this. This being said, I don't see any problem 
>> deferring to kito on this issue, since he is the one with the 
>> knowledge on this subject.
> 
> Pretty much my feeling, but if it were needed/wanted, it would be an alt 
> sub-project as it reaches further than just os x.

You are both interpreting the word 'sub-project' in a way I didn't mean 
it.  I don't know the right word in english, and perhaps 'track' comes 
close.  But since it appears that you misunderstood my actual message, 
I'll try again:

I would just like Kito to take an active role in the process he's in. 
This means that I'd like to see him coordinating, managing and 
conducting, as I obviously lack the required knowledge to do so.

Don't nail me on the 'sub-project' thing.  Forget about it.


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

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@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: [gentoo-osx] The road ahead?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-osx] The road ahead?

[Kito]

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: [gentoo-osx] The road ahead?

[m h]

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

Well, if this is "round two" (which seems kind of weird since it's
backported from v2.1 to 2.0...).  I'm interested in tracking the
"official" version as closely as possible. Maybe I should test this
version out on FC4.  What will "round three", etc, look like (are
there missing features, is it just testing, getting ebuilds converted,
evangelism)?

Kito- Could you please elaborate on the bootstrap process?   Perhaps
we could put it in the wiki?  Regarding changes to ebuilds, yes I
agree small (or no) changes is preferred.  I went ahead and installed
apache2 in my prefixed environment and it was relatively
straightforward.

Brian-  Do you have any idea of the roadmap for prefix getting into
portage?  Would it possibly get into 2.0? 2.1? Rewrite?  What will
determine this?

matt

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 1:16 PM, m h wrote:

> On 10/31/05, Kito <kito@gentoo.org> wrote:
>>
>> 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...
>
> Well, if this is "round two" (which seems kind of weird since it's
> backported from v2.1 to 2.0...).

Well. the 2.1 branch has been officially killed, which is the version  
Haubi did his original work on, so Brian back ported it just so we  
could start testing out the ebuilds in an overlay and have a working  
prototype.

> I'm interested in tracking the
> "official" version as closely as possible. Maybe I should test this
> version out on FC4.  What will "round three", etc, look like (are
> there missing features, is it just testing, getting ebuilds converted,
> evangelism)?
>
> Kito- Could you please elaborate on the bootstrap process?

Well, I started by building a toolchain manually in the prefix  
(gcc,cctools[apples linker/assembler], coreutils, make, python, bash  
and some others I'm forgetting), then configured and installed  
portage. Once portage was up and running I just started importing the  
base-system ebuilds to the overlay and merging as I went along. On a  
FC4 system, you could probably just use some symlinks instead of  
manually building a toolchain for bootstrap.

I've finished the base-system ebuilds for a Darwin/OS X prefix, but  
for linux you will still need a few extra that I haven't done yet,  
like binutils, libtool, and gcc[1]. I'm going back and doing some  
cleanup and additional testing, should have it checked into svn later  
this week. Definitely want to get this working on as many archs as  
possible, so any help is welcome.

>   Perhaps
> we could put it in the wiki?

I was going to create a project page in xml under the gentoo-alt  
page, but a wiki might be a better idea, especially if a few other  
non-gentoo devs want to start helping out with the linux/aix/solaris  
stuff.

> Regarding changes to ebuilds, yes I
> agree small (or no) changes is preferred.

Yeah, by far the biggest change needed right now is `make DESTDIR=$ 
{DEST} install`. I've made functions to address the ebuilds that  
don't use econf, so the changes are very very slight, and with some  
more work could probably even be lessened further.

> I went ahead and installed
> apache2 in my prefixed environment and it was relatively
> straightforward.

Yeah, I'm having great luck so far, running gtk+, jack, and ardour  
out of the prefix with no problems and very minor ebuild changes.

>
> Brian-  Do you have any idea of the roadmap for prefix getting into
> portage?  Would it possibly get into 2.0? 2.1? Rewrite?  What will
> determine this?

I'll let Brian answer this, but I'm fairly certain there is no chance  
of this making it into the 2.0 series, 2.1 is dead, so 3.0 will have  
to be our saviour (boooo! hsssss! bad pun)

--Kito


[1] I chose to use the apple branch of gcc, as most upstream packages  
have started expecting it on Darwin systems, and have started using  
apple-specific flags such as -mdynamic-no-pic and -no-cpp-precomp and  
-faltivec, so I figured this is the path of least resistance. Plus  
this allows us to take advantage of Frameworks...

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Nathan]

> [1] I chose to use the apple branch of gcc, as most upstream packages
> have started expecting it on Darwin systems, and have started using
> apple-specific flags such as -mdynamic-no-pic and -no-cpp-precomp and
> -faltivec, so I figured this is the path of least resistance. Plus
> this allows us to take advantage of Frameworks...

Coolness.  I assumed that upstream support for apple's gcc hadn't
occurred.  Glad to be wrong if it means we get extras from Apple.

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

I'm also happy to see this way as an option at least.  I don't have good 
arguments yet, but I feel there's more in it somehow.

On the other hand, (turning my head over to *our* glep42) it imposes a 
problem that needs to be addressable somehow by having the handles to 
dynamically do the right things depending on apple/gnu cc-suite, if you 
get what I mean.

Nathan wrote:
>> [1] I chose to use the apple branch of gcc, as most upstream packages
>> have started expecting it on Darwin systems, and have started using
>> apple-specific flags such as -mdynamic-no-pic and -no-cpp-precomp and
>> -faltivec, so I figured this is the path of least resistance. Plus
>> this allows us to take advantage of Frameworks...
> 
> Coolness.  I assumed that upstream support for apple's gcc hadn't
> occurred.  Glad to be wrong if it means we get extras from Apple.
> 

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

Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 2:21 PM, Grobian wrote:

> I'm also happy to see this way as an option at least.  I don't have  
> good arguments yet, but I feel there's more in it somehow.
>
> On the other hand, (turning my head over to *our* glep42) it  
> imposes a problem that needs to be addressable somehow by having  
> the handles to dynamically do the right things depending on apple/ 
> gnu cc-suite, if you get what I mean.

Wouldn't extending tc_get* be sufficient?

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

Kito wrote:
> 
> On Nov 1, 2005, at 2:21 PM, Grobian wrote:
> 
>> I'm also happy to see this way as an option at least.  I don't have 
>> good arguments yet, but I feel there's more in it somehow.
>>
>> On the other hand, (turning my head over to *our* glep42) it imposes a 
>> problem that needs to be addressable somehow by having the handles to 
>> dynamically do the right things depending on apple/gnu cc-suite, if 
>> you get what I mean.
> 
> Wouldn't extending tc_get* be sufficient?

Probably, but at the moment we already make the wrong assumption of doing:

#ifdef __APPLE__
#include <malloc/malloc.h>
#else
#include <malloc.h>
#endif

and then calling it a darwin patch.  It's an apple patch basically, but 
I don't know the darwin counterpart, if it would exist.

What I want to say, is that not only do we need to have the right 
handles to get the data we need, we also need the right methods (maybe 
even configure checks?) to do the right things depending on another 
compiler/linker.  Upstream uses __APPLE__ as well.  We can't expect 
upstream to have support for Gentoo's setup with standard 
compiler/linker, so if we would like to support that I think we should 
consider using conditionals again and/or maybe override some defines the 
hard way to get what we want.

Conclusion at my side of the story is that going the way of using (or 
immitating) Apple's build tools is the one of least resistance for now.


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

Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 2:45 PM, Grobian wrote:

>
>
> Kito wrote:
>> On Nov 1, 2005, at 2:21 PM, Grobian wrote:
>>> I'm also happy to see this way as an option at least.  I don't  
>>> have good arguments yet, but I feel there's more in it somehow.
>>>
>>> On the other hand, (turning my head over to *our* glep42) it  
>>> imposes a problem that needs to be addressable somehow by having  
>>> the handles to dynamically do the right things depending on apple/ 
>>> gnu cc-suite, if you get what I mean.
>> Wouldn't extending tc_get* be sufficient?
>
> Probably, but at the moment we already make the wrong assumption of  
> doing:
>
> #ifdef __APPLE__
> #include <malloc/malloc.h>
> #else
> #include <malloc.h>
> #endif
>
> and then calling it a darwin patch.  It's an apple patch basically,  
> but I don't know the darwin counterpart, if it would exist.

Its the same on darwin. Remember, the saying is 'Never ever try to  
determine if you are on Darwin or OS X, just check for  
functionality". The above example is fine, however this would  
obviously not be:

#ifdef __APPLE__
#include <QuickTime/QuickTime.h>
#endif

As this blindly assumes the proprietary frameworks are available.  
Anyway, I suppose custom defines are always an option too, though I'm  
not sure its really warranted at this point...

>
> What I want to say, is that not only do we need to have the right  
> handles to get the data we need, we also need the right methods  
> (maybe even configure checks?) to do the right things depending on  
> another compiler/linker.

The linker will always be the same for the foreseeable future on any  
Darwin/OS X system, the compiler can and will change however...I  
really would't be too surprised to see them start shipping ICC at  
some point...

> Upstream uses __APPLE__ as well.  We can't expect upstream to have  
> support for Gentoo's setup with standard compiler/linker, so if we  
> would like to support that I think we should consider using  
> conditionals again and/or maybe override some defines the hard way  
> to get what we want.
>
> Conclusion at my side of the story is that going the way of using  
> (or immitating) Apple's build tools is the one of least resistance  
> for now.

Yeah, pretty much my same thought. The big advantage, is since we can  
build from source unlike when relying on Xcode, we can add our own  
goodies to make ebuild maintaining a little easier... the -Wl,-z,now  
situation comes to mind, patching our ld to deal with those options  
would be a far cleaner solution than having to fight it out on -dev@  
trying to get linux folks to change their ways...

--Kito

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

Kito wrote:
> The linker will always be the same for the foreseeable future on any 
> Darwin/OS X system, the compiler can and will change however...I really 
> would't be too surprised to see them start shipping ICC at some point...

Me neither... I guess it is even guaranteed to be so, as you can get big 
speedups by using it.

> Yeah, pretty much my same thought. The big advantage, is since we can 
> build from source unlike when relying on Xcode, we can add our own 
> goodies to make ebuild maintaining a little easier... the -Wl,-z,now 
> situation comes to mind, patching our ld to deal with those options 
> would be a far cleaner solution than having to fight it out on -dev@ 
> trying to get linux folks to change their ways...

The same situation would be on Solaris, where using Sun's CC is prefered 
(speed wise) over GCC.  Since Solaris 10 is open source, you would be 
able to do the same to the linker on Solaris.  l33t!


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

Re: [gentoo-osx] The road ahead?

[m h]

> >
> > Well, if this is "round two" (which seems kind of weird since it's
> > backported from v2.1 to 2.0...).
>
> Well. the 2.1 branch has been officially killed, which is the version
> Haubi did his original work on, so Brian back ported it just so we
> could start testing out the ebuilds in an overlay and have a working
> prototype.

Well, I'm interested in testing the 2.0 version if possible.  3.0
timeframe is start of next year?

>
> > I'm interested in tracking the
> > "official" version as closely as possible. Maybe I should test this
> > version out on FC4.  What will "round three", etc, look like (are
> > there missing features, is it just testing, getting ebuilds converted,
> > evangelism)?
> >
> > Kito- Could you please elaborate on the bootstrap process?
>
> Well, I started by building a toolchain manually in the prefix
> (gcc,cctools[apples linker/assembler], coreutils, make, python, bash
> and some others I'm forgetting), then configured and installed
> portage. Once portage was up and running I just started importing the
> base-system ebuilds to the overlay and merging as I went along. On a
> FC4 system, you could probably just use some symlinks instead of
> manually building a toolchain for bootstrap.
>

Yeah on linux you could get by pretty easily.  But if you want to
allow end users to add new archs (could be distro, or posix operating
system) wouldn't it be easier to have something like haubi's
bootstrapper?

> I've finished the base-system ebuilds for a Darwin/OS X prefix, but
> for linux you will still need a few extra that I haven't done yet,
> like binutils, libtool, and gcc[1]. I'm going back and doing some
> cleanup and additional testing, should have it checked into svn later
> this week. Definitely want to get this working on as many archs as
> possible, so any help is welcome.
>
> >   Perhaps
> > we could put it in the wiki?
>
> I was going to create a project page in xml under the gentoo-alt
> page, but a wiki might be a better idea, especially if a few other
> non-gentoo devs want to start helping out with the linux/aix/solaris
> stuff.
>

Making the information public is better than no information.  It seems
like it is better suited to be in the wiki right now, since end users
(non-gento devs) could add/edit/fix things in it.

> > Regarding changes to ebuilds, yes I
> > agree small (or no) changes is preferred.
>
> Yeah, by far the biggest change needed right now is `make DESTDIR=$
> {DEST} install`. I've made functions to address the ebuilds that
> don't use econf, so the changes are very very slight, and with some
> more work could probably even be lessened further.
>

So DEST is PREFIX now?

> > I went ahead and installed
> > apache2 in my prefixed environment and it was relatively
> > straightforward.
>
> Yeah, I'm having great luck so far, running gtk+, jack, and ardour
> out of the prefix with no problems and very minor ebuild changes.
>

That is awesome.
> >
> > Brian-  Do you have any idea of the roadmap for prefix getting into
> > portage?  Would it possibly get into 2.0? 2.1? Rewrite?  What will
> > determine this?
>
> I'll let Brian answer this, but I'm fairly certain there is no chance
> of this making it into the 2.0 series, 2.1 is dead, so 3.0 will have
> to be our saviour (boooo! hsssss! bad pun)

Looking forward to 3.0 then....

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 4:01 PM, m h wrote:

>>>
>>> Well, if this is "round two" (which seems kind of weird since it's
>>> backported from v2.1 to 2.0...).
>>
>> Well. the 2.1 branch has been officially killed, which is the version
>> Haubi did his original work on, so Brian back ported it just so we
>> could start testing out the ebuilds in an overlay and have a working
>> prototype.
>
> Well, I'm interested in testing the 2.0 version if possible.

Few more days, and should have an updated tarball to post for testing.

> 3.0
> timeframe is start of next year?

I think its mostly a question of manpower...

>
>>
>>> I'm interested in tracking the
>>> "official" version as closely as possible. Maybe I should test this
>>> version out on FC4.  What will "round three", etc, look like (are
>>> there missing features, is it just testing, getting ebuilds  
>>> converted,
>>> evangelism)?
>>>
>>> Kito- Could you please elaborate on the bootstrap process?
>>
>> Well, I started by building a toolchain manually in the prefix
>> (gcc,cctools[apples linker/assembler], coreutils, make, python, bash
>> and some others I'm forgetting), then configured and installed
>> portage. Once portage was up and running I just started importing the
>> base-system ebuilds to the overlay and merging as I went along. On a
>> FC4 system, you could probably just use some symlinks instead of
>> manually building a toolchain for bootstrap.
>>
>
> Yeah on linux you could get by pretty easily.  But if you want to
> allow end users to add new archs (could be distro, or posix operating
> system) wouldn't it be easier to have something like haubi's
> bootstrapper?

End users would simply download a stage tarball, just like a  
traditional gentoo install. People porting to other archs are welcome  
to try toolsbox, it was just more work for me to port toolsbox to  
Darwin than it was to build a toolchain manually and rebuild  
everything via portage.

>
>> I've finished the base-system ebuilds for a Darwin/OS X prefix, but
>> for linux you will still need a few extra that I haven't done yet,
>> like binutils, libtool, and gcc[1]. I'm going back and doing some
>> cleanup and additional testing, should have it checked into svn later
>> this week. Definitely want to get this working on as many archs as
>> possible, so any help is welcome.
>>
>>>   Perhaps
>>> we could put it in the wiki?
>>
>> I was going to create a project page in xml under the gentoo-alt
>> page, but a wiki might be a better idea, especially if a few other
>> non-gentoo devs want to start helping out with the linux/aix/solaris
>> stuff.
>>
>
> Making the information public is better than no information.  It seems
> like it is better suited to be in the wiki right now, since end users
> (non-gento devs) could add/edit/fix things in it.

Sounds good to me. I'll probably add another page and leave the  
existing one that describes haubis method there for posterity.

>
>>> Regarding changes to ebuilds, yes I
>>> agree small (or no) changes is preferred.
>>
>> Yeah, by far the biggest change needed right now is `make DESTDIR=$
>> {DEST} install`. I've made functions to address the ebuilds that
>> don't use econf, so the changes are very very slight, and with some
>> more work could probably even be lessened further.
>>
>
> So DEST is PREFIX now?

No. Most ebuilds do things in src_install() like `mv ${D}/usr/bin $ 
{D}/bin` and/or `[[ -e ${ROOT}/foo/bar]] && boof`

So instead of being faced with a lot of changes in virtually every  
ebuild in the tree, we shifted the meaning of the vars slightly.
So now, in the ebuild environment:

D=${BUILDDIR}/image/${PREFIX}
DEST=${BUILDDIR}/image
ROOT=${ROOT}/${PREFIX}

SO, really the only place you would ever use ${DEST} is `make DESTDIR= 
${DEST} install` as there should be no valid reason to ever touch the  
image dir directly.

This drastically reduces the number of changes required to get most  
ebuilds prefix compliant.

--Kito
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[m h]

On 11/1/05, Kito <kito@gentoo.org> wrote:
>
> On Nov 1, 2005, at 4:01 PM, m h wrote:
>
> >>>
> >>> Well, if this is "round two" (which seems kind of weird since it's
> >>> backported from v2.1 to 2.0...).
> >>
> >> Well. the 2.1 branch has been officially killed, which is the version
> >> Haubi did his original work on, so Brian back ported it just so we
> >> could start testing out the ebuilds in an overlay and have a working
> >> prototype.
> >
> > Well, I'm interested in testing the 2.0 version if possible.
>
> Few more days, and should have an updated tarball to post for testing.
>

Let me know when there is a tarball, I'd like to give it a go.  Will
there be a wiki page to go with it?

thanks

matt

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[m h]

Kito-

How long do you suppose it will be til us common folk can get a tarball?

thanks
matt

On 11/4/05, m h <sesquile@gmail.com> wrote:
> On 11/1/05, Kito <kito@gentoo.org> wrote:
> >
> > On Nov 1, 2005, at 4:01 PM, m h wrote:
> >
> > >>>
> > >>> Well, if this is "round two" (which seems kind of weird since it's
> > >>> backported from v2.1 to 2.0...).
> > >>
> > >> Well. the 2.1 branch has been officially killed, which is the version
> > >> Haubi did his original work on, so Brian back ported it just so we
> > >> could start testing out the ebuilds in an overlay and have a working
> > >> prototype.
> > >
> > > Well, I'm interested in testing the 2.0 version if possible.
> >
> > Few more days, and should have an updated tarball to post for testing.
> >
>
> Let me know when there is a tarball, I'd like to give it a go.  Will
> there be a wiki page to go with it?
>
> thanks
>
> matt
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Grobian]

getting impatient, eh?

I AM FIRST!!!!


m h wrote:
> Kito-
> 
> How long do you suppose it will be til us common folk can get a tarball?
> 
> thanks
> matt
> 
> On 11/4/05, m h <sesquile@gmail.com> wrote:
>> On 11/1/05, Kito <kito@gentoo.org> wrote:
>>> On Nov 1, 2005, at 4:01 PM, m h wrote:
>>>
>>>>>> Well, if this is "round two" (which seems kind of weird since it's
>>>>>> backported from v2.1 to 2.0...).
>>>>> Well. the 2.1 branch has been officially killed, which is the version
>>>>> Haubi did his original work on, so Brian back ported it just so we
>>>>> could start testing out the ebuilds in an overlay and have a working
>>>>> prototype.
>>>> Well, I'm interested in testing the 2.0 version if possible.
>>> Few more days, and should have an updated tarball to post for testing.
>>>
>> Let me know when there is a tarball, I'd like to give it a go.  Will
>> there be a wiki page to go with it?
>>
>> thanks
>>
>> matt
>>
> 

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

Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 8, 2005, at 10:53 AM, Grobian wrote:

> getting impatient, eh?
>
> I AM FIRST!!!!
>
>
> m h wrote:
>> Kito-
>> How long do you suppose it will be til us common folk can get a  
>> tarball?

Hehe, sorry its taking so long... got slowed down by work-work a  
little. I need to clean up my changes and split new patches,  
hopefully a couple more days(famous last words I know)....
Thanks for being patient ;)

--Kito
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[m h]

thanks for the update.  I'll be patient...

On 11/8/05, Kito <kito@gentoo.org> wrote:
>
> On Nov 8, 2005, at 10:53 AM, Grobian wrote:
>
> > getting impatient, eh?
> >
> > I AM FIRST!!!!
> >
> >
> > m h wrote:
> >> Kito-
> >> How long do you suppose it will be til us common folk can get a
> >> tarball?
>
> Hehe, sorry its taking so long... got slowed down by work-work a
> little. I need to clean up my changes and split new patches,
> hopefully a couple more days(famous last words I know)....
> Thanks for being patient ;)
>
> --Kito
> --
> gentoo-osx@gentoo.org mailing list
>
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[m h]

Kito-

Just pinging again.  Can you provide a status update?  Is there a
tarball/patch for prefix available somewhere?

thanks

matt

On 11/8/05, m h <sesquile@gmail.com> wrote:
> thanks for the update.  I'll be patient...
>
> On 11/8/05, Kito <kito@gentoo.org> wrote:
> >
> > On Nov 8, 2005, at 10:53 AM, Grobian wrote:
> >
> > > getting impatient, eh?
> > >
> > > I AM FIRST!!!!
> > >
> > >
> > > m h wrote:
> > >> Kito-
> > >> How long do you suppose it will be til us common folk can get a
> > >> tarball?
> >
> > Hehe, sorry its taking so long... got slowed down by work-work a
> > little. I need to clean up my changes and split new patches,
> > hopefully a couple more days(famous last words I know)....
> > Thanks for being patient ;)
> >
> > --Kito
> > --
> > gentoo-osx@gentoo.org mailing list
> >
> >
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Kito]

On Dec 4, 2005, at 11:19 PM, m h wrote:

> Kito-
>
> Just pinging again.  Can you provide a status update?  Is there a
> tarball/patch for prefix available somewhere?

Apologies once again for the lack of communication....we have been  
getting work done though =)

Portage with the autoconf/prefix modifications is in its own svn  
branch now, as well as the prefix aware ebuild tree. Developers can  
find them at:

	svn+ssh://{USERNAME}@svn.gentoo.org/var/svnroot/portage/main/ 
branches/prefix
	svn+ssh://{USERNAME}@svn.gentoo.org/var/svnroot/gentoo-alt/trunk/ 
prefix-overlay

anon svn access for portage is at:

	svn co svn://twobit.net/portage

Sadly, whats in svn is not working at the moment, the recent cache  
rewrite caused some problems, so if you want something that works 
(sorta) right now, grab the snapshot below.
Currently there is no anon access to the ebuild repo, but we should  
have daily snapshots available on the mirrors soon, but here are  
current snapshots:

	http://dev.gentoo.org/~kito/distfiles/portage-2.0.53.03.tar.gz
	http://dev.gentoo.org/~kito/distfiles/prefix-overlay-05122005.tar.gz

to install portage, just run:

	./configure --prefix=${PREFIX}/usr --with-offset-prefix=${PREFIX} &&  
make && make install

replacing ${PREFIX} with whatever path you want...

I've only taken care of the Darwin/OS X side of things, so for ELF  
systems you'll still need ebuilds for gcc and binutils, a make.conf,  
and a valid profile. How you bootstrap is up to you, you can either  
create symlinks to your host systems toolchain, manually compile  
them, or use haubis toolsbox.

There are tons and tons of bugs and missing functionality, but its a  
start =)

Still hope to get a small project page/wiki going at some point when  
time permits, any help is appreciated.

--Kito

>
> thanks
>
> matt
>
> On 11/8/05, m h <sesquile@gmail.com> wrote:
>> thanks for the update.  I'll be patient...
>>
>> On 11/8/05, Kito <kito@gentoo.org> wrote:
>>>
>>> On Nov 8, 2005, at 10:53 AM, Grobian wrote:
>>>
>>>> getting impatient, eh?
>>>>
>>>> I AM FIRST!!!!
>>>>
>>>>
>>>> m h wrote:
>>>>> Kito-
>>>>> How long do you suppose it will be til us common folk can get a
>>>>> tarball?
>>>
>>> Hehe, sorry its taking so long... got slowed down by work-work a
>>> little. I need to clean up my changes and split new patches,
>>> hopefully a couple more days(famous last words I know)....
>>> Thanks for being patient ;)
>>>
>>> --Kito
>>> --
>>> gentoo-osx@gentoo.org mailing list
>>>
>>>
>>
>
> -- 
> gentoo-osx@gentoo.org mailing list
>

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Tue, Nov 01, 2005 at 02:10:03PM -0600, Kito wrote:
> I'll let Brian answer this, but I'm fairly certain there is no chance  
> of this making it into the 2.0 series, 2.1 is dead, so 3.0 will have  
> to be our saviour (boooo! hsssss! bad pun)

No way in hell on 2.0; 2.1 was released dead (the major changes of it 
are a year old), 3.0 would be the only _potential_ portage target.

Why did I say potential?

Cause I'm after making an ancillary point so everyone is on the same 
page here- portage will *not* have any prefix support without the 
ebuild changes being vetted by gentoo community.

What's being worked on is a prototype- the prototype will be useful on 
it's own, but the main point of it is demonstrating that it's doable 
and the pros/cons of it.

Please keep this in mind.  Bit of a reality check (kito and I are 
operating under this)- comments of the sort "when portage supports 
prefix "...

Portage will only mainline support PREFIX if devs agree to the underlying 
ebuild changes.  So... help make it clean, but be aware of the rules being 
operated under please.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-osx] The road ahead?

[Kito]

[ Leaving message intact as I feel it should be re-iterated even yet  
again :p ]
On Nov 1, 2005, at 8:33 PM, Brian Harring wrote:

> On Tue, Nov 01, 2005 at 02:10:03PM -0600, Kito wrote:
>> I'll let Brian answer this, but I'm fairly certain there is no chance
>> of this making it into the 2.0 series, 2.1 is dead, so 3.0 will have
>> to be our saviour (boooo! hsssss! bad pun)
>
> No way in hell on 2.0; 2.1 was released dead (the major changes of it
> are a year old), 3.0 would be the only _potential_ portage target.
>
> Why did I say potential?
>
> Cause I'm after making an ancillary point so everyone is on the same
> page here- portage will *not* have any prefix support without the
> ebuild changes being vetted by gentoo community.
>
> What's being worked on is a prototype- the prototype will be useful on
> it's own, but the main point of it is demonstrating that it's doable
> and the pros/cons of it.
>
> Please keep this in mind.  Bit of a reality check (kito and I are
> operating under this)- comments of the sort "when portage supports
> prefix "...
>
> Portage will only mainline support PREFIX if devs agree to the  
> underlying
> ebuild changes.  So... help make it clean, but be aware of the  
> rules being
> operated under please.
> ~harring

This is the other area where the more help we have the better. If  
anyone is having doubts about jumping in on the tech side of prefix  
support, you can also put your lawyer hat on and start researching  
and preparing our case to the jury. We will need an absitively  
posolutely 100% bullet proof GLEP that covers every aspect of the  
impact this will have on the Gentoo project and community as a whole.

Sooooo, maybe we should actually start a sort of community drafted  
GLEP, slowly and methodically nailing down all the benefits, and all  
the drawbacks, of this being adopted. No need to rush it, it can just  
be something that gets improved as we go along, so when it comes time  
to show our work and go through the official GLEP process, we aren't  
caught with our pants down.

A good start would probably be going back through previous ML archive  
threads and making sure all the relevant discussion is incorporated.

Hmmm...a GLEP wiki page for this could be interesting....might be  
easier than trading diffs back and forth via ML.

--Kito
-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

On Tue, Nov 01, 2005 at 09:00:25PM -0600, Kito wrote:
> This is the other area where the more help we have the better. If  
> anyone is having doubts about jumping in on the tech side of prefix  
> support, you can also put your lawyer hat on and start researching  
> and preparing our case to the jury. We will need an absitively  
> posolutely 100% bullet proof GLEP that covers every aspect of the  
> impact this will have on the Gentoo project and community as a whole.
> 
> Sooooo, maybe we should actually start a sort of community drafted  
> GLEP, slowly and methodically nailing down all the benefits, and all  
> the drawbacks, of this being adopted. No need to rush it, it can just  
> be something that gets improved as we go along, so when it comes time  
> to show our work and go through the official GLEP process, we aren't  
> caught with our pants down.
> 
> A good start would probably be going back through previous ML archive  
> threads and making sure all the relevant discussion is incorporated.
> 
> Hmmm...a GLEP wiki page for this could be interesting....might be  
> easier than trading diffs back and forth via ML.
Wiki/list of pros, cons, issues, how they're addressed, etc.

Would avoid an actual glep at this point for the container for this 
information ... too easy for someone to miss the giant "this is a work 
in progress and not yet proposed" disclaimers, and trigger a bit of 
unneeded flaming.

Plus... wiki style pages allow us to refine/nail down the seperate 
chunks, and pull it all together in the end.
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-osx] The road ahead?

[Nathan]

On 11/1/05, Brian Harring <ferringb@gentoo.org> wrote:
> On Tue, Nov 01, 2005 at 02:10:03PM -0600, Kito wrote:
> > I'll let Brian answer this, but I'm fairly certain there is no chance
> > of this making it into the 2.0 series, 2.1 is dead, so 3.0 will have
> > to be our saviour (boooo! hsssss! bad pun)
>
> No way in hell on 2.0; 2.1 was released dead (the major changes of it
> are a year old), 3.0 would be the only _potential_ portage target.
>
> Why did I say potential?
>
> Cause I'm after making an ancillary point so everyone is on the same
> page here- portage will *not* have any prefix support without the
> ebuild changes being vetted by gentoo community.

I had to look up 'ancillary' and 'vet.'  Vocabulary++.

> What's being worked on is a prototype- the prototype will be useful on
> it's own, but the main point of it is demonstrating that it's doable
> and the pros/cons of it.
>
> Please keep this in mind.  Bit of a reality check (kito and I are
> operating under this)- comments of the sort "when portage supports
> prefix "...
>
> Portage will only mainline support PREFIX if devs agree to the underlying
> ebuild changes.  So... help make it clean, but be aware of the rules being
> operated under please.

Very good to know, especieally as I was one of those assuming it was a
"when" and not an "if."  Do the 'rules being operated under' consist
of what you mentioned above (i.e. prefixed installs are a one-off
prototype unless/until everyone accepts it), or is there more to it
than that?

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] The road ahead?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]

On Tue, Nov 01, 2005 at 09:16:25PM -0700, Nathan wrote:
> > What's being worked on is a prototype- the prototype will be useful on
> > it's own, but the main point of it is demonstrating that it's doable
> > and the pros/cons of it.
> >
> > Please keep this in mind.  Bit of a reality check (kito and I are
> > operating under this)- comments of the sort "when portage supports
> > prefix "...
> >
> > Portage will only mainline support PREFIX if devs agree to the underlying
> > ebuild changes.  So... help make it clean, but be aware of the rules being
> > operated under please.
> 
> Very good to know, especieally as I was one of those assuming it was a
> "when" and not an "if."  Do the 'rules being operated under' consist
> of what you mentioned above (i.e. prefixed installs are a one-off
> prototype unless/until everyone accepts it), or is there more to it
> than that?

Nope, that's pretty much it.

PREFIX is a potentially large set of tweaks to the ebuild env 
requirements, some of the changes being a bit intricate- while it's 
not hard to make portage do said tweaks, those changes won't be 
mainlined in portage without gentoo devs agreeing to it.

Basically... I can't just mandate "y'all are now going to support 
this"- I could try it, but I also probably would lose a knee cap or 
two from the ensuing beat down.

Prototype work pretty much comes down to stepping up and taking a 
serious thwack at this thing so that a decision can be reached, rather 
then sitting back and making zero progress towards it arguing over it. 
:)
~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-osx] The road ahead?

[m h]

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: [gentoo-osx] The road ahead?

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-osx] The road ahead?

[Kito]

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