Mailing List Archive: Gentoo: OSX

The road ahead?

1 2 3

View All

Index | Next | Previous | View Threaded

nathan.stocks at gmail

Nov 1, 2005, 11:09 AM

Post #26 of 58 (1131 views)
Permalink

Re: The road ahead? [In reply to]

On 11/1/05, Grobian <grobian [at] gentoo> 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 [at] gentoo mailing list

sesquile at gmail

Nov 1, 2005, 12:03 PM

Post #27 of 58 (1134 views)
Permalink

Re: The road ahead? [In reply to]

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

On 11/1/05, Nathan <nathan.stocks [at] gmail> wrote:
> On 11/1/05, Grobian <grobian [at] gentoo> 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 [at] gentoo mailing list
>
>

--
gentoo-osx [at] gentoo mailing list

grobian at gentoo

Nov 1, 2005, 12:13 PM

Post #28 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

nathan.stocks at gmail

Nov 1, 2005, 12:14 PM

Post #29 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

On 11/1/05, m h <sesquile [at] gmail> 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 [at] gentoo mailing list

sesquile at gmail

Nov 1, 2005, 12:16 PM

Post #30 of 58 (1138 views)
Permalink

Re: The road ahead? [In reply to]

On 10/31/05, Kito <kito [at] gentoo> 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 [at] gentoo mailing list

sesquile at gmail

Nov 1, 2005, 12:32 PM

Post #31 of 58 (1137 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo> 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 [at] gentoo mailing list
>
>

--
gentoo-osx [at] gentoo mailing list

dirk.schoenberger at sz-online

Nov 1, 2005, 12:35 PM

Post #32 of 58 (1139 views)
Permalink

Re: The road ahead? [In reply to]

> > 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 [at] gentoo mailing list

grobian at gentoo

Nov 1, 2005, 12:36 PM

Post #33 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo> 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 [at] gentoo mailing list
>>
>>
>

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead
--
gentoo-osx [at] gentoo mailing list

sesquile at gmail

Nov 1, 2005, 12:45 PM

Post #34 of 58 (1143 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo> 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 [at] gentoo> 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 [at] gentoo mailing list
> >>
> >>
> >
>
> --
> Fabian Groffen
> Gentoo for Mac OS X Project -- Interim Lead
> --
> gentoo-osx [at] gentoo mailing list
>
>

--
gentoo-osx [at] gentoo mailing list

kito at gentoo

Nov 1, 2005, 1:10 PM

Post #35 of 58 (1139 views)
Permalink

Re: The road ahead? [In reply to]

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

> On 10/31/05, Kito <kito [at] gentoo> 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 [at] gentoo mailing list

nathan.stocks at gmail

Nov 1, 2005, 1:16 PM

Post #36 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

> [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 [at] gentoo mailing list

grobian at gentoo

Nov 1, 2005, 1:21 PM

Post #37 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

kito at gentoo

Nov 1, 2005, 1:37 PM

Post #38 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

grobian at gentoo

Nov 1, 2005, 1:45 PM

Post #39 of 58 (1134 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

kito at gentoo

Nov 1, 2005, 1:58 PM

Post #40 of 58 (1137 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

grobian at gentoo

Nov 1, 2005, 2:05 PM

Post #41 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

sesquile at gmail

Nov 1, 2005, 3:01 PM

Post #42 of 58 (1137 views)
Permalink

Re: The road ahead? [In reply to]

> >
> > 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 [at] gentoo mailing list

J4rg0n at gentoo

Nov 1, 2005, 3:45 PM

Post #43 of 58 (1131 views)
Permalink

Re: The road ahead? [In reply to]

-----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 [at] gentoo mailing list

kito at gentoo

Nov 1, 2005, 3:55 PM

Post #44 of 58 (1137 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

kito at gentoo

Nov 1, 2005, 5:06 PM

Post #45 of 58 (1136 views)
Permalink

Re: The road ahead? [In reply to]

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 [at] gentoo mailing list

ferringb at gentoo

Nov 1, 2005, 7:33 PM

Post #46 of 58 (1135 views)
Permalink

Re: The road ahead? [In reply to]

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

kito at gentoo

Nov 1, 2005, 8:00 PM

Post #47 of 58 (1138 views)
Permalink

Re: The road ahead? [In reply to]

[. 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 [at] gentoo mailing list

ferringb at gentoo

Nov 1, 2005, 9:12 PM

Post #48 of 58 (1140 views)
Permalink

Re: The road ahead? [In reply to]

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

nathan.stocks at gmail

Nov 1, 2005, 9:16 PM

Post #49 of 58 (1134 views)
Permalink

Re: The road ahead? [In reply to]

On 11/1/05, Brian Harring <ferringb [at] gentoo> 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 [at] gentoo mailing list

ferringb at gentoo

Nov 1, 2005, 10:52 PM

Post #50 of 58 (1135 views)
Permalink

Re: The road ahead? [In reply to]

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

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads