Mailing List Archive

> As you will all know after the last GWN, we are a prefixed project. I
> tried to tell the GWN folks that we aren't, but apparently they didn't
> believe me. Who am I, heh? For sure, I can't know. If there are more
> things that more or less require some discretion, due to mail volumes,
> extreme beta-bility, etc., please don't hesitate to catch me in
> non-recordable places such as IRC or personal email. I prefer the
> latter. Perhaps it is also a good idea to keep CVS/SVN commit messages
> a bit vague from now on.[1]
>
> Anywayz, I wrote a new page yesterday:
> http://www.gentoo.org/proj/en/gentoo-alt/macos/targets.xml

Sooo, after reading your new page I don't understand your comment
about not being a prefixed project, unless you are talking about your
defined distinction between "Gentoo for Mac OS X" and "Gentoo Portage
for Mac OS X."


"Because "Darwin Portage" is not suitable for a mainstream user
distribution, it was chosen to change the direction towards "Gentoo
Portage for Mac OS X" [PREFIXED PROJECT], to enable Gentoo's Mac OS X
project to continue and innovate again.
...
but large investments are not being done, unless they are directly
reusable in the prefixed environment."

^-- Whatever you call it, it appears you've officially chosen to focus
on the prefixed path. Good news to me, as a working prefixed system
is what I've been waiting for for over a year now. (Last December
pvdabeel was saying he working on a prototype that should be usable in
January....then February, then maybe March, then he disappeared.)

I appreciate the labels+definitions for the alternatives. That makes
it loads easier to refer to things and have some reasonable hope that
others will understand what you're referring to.

> The page should fill a gap in the explanation of our road ahead, and my
> vision on the plcament of various things. Comments are welcome, both
> text-wise as content-wise. The document efforts might be re-used at a
> later stage on Gentoo/Alt level. I chose to put it in our garden,
> because the focus of development comes from our team at the moment.

Actually, the page quite admirably explained the past, the
alternatives, and why the present focus is (rightly) turning towards
prefixed efforts. The future ("road ahead") wasn't really explicitly
mentioned. I'd welcome a tentative future timeline at the bottom of
the doc, if possible. The common question outside of the core dev
team seems to be "When will there be something that works that I can
use [and/or contribute to]?"

~ Nathan

--
gentoo-osx@gentoo.org mailing list

On 12-12-2005 09:36:52 -0700, Nathan wrote:
> > Anywayz, I wrote a new page yesterday:
> > http://www.gentoo.org/proj/en/gentoo-alt/macos/targets.xml
>
> Sooo, after reading your new page I don't understand your comment
> about not being a prefixed project, unless you are talking about your
> defined distinction between "Gentoo for Mac OS X" and "Gentoo Portage
> for Mac OS X."

We are *not* prefixed. This a page on what we would *like* to be,
somehow.

> ^-- Whatever you call it, it appears you've officially chosen to focus
> on the prefixed path. Good news to me, as a working prefixed system
> is what I've been waiting for for over a year now. (Last December
> pvdabeel was saying he working on a prototype that should be usable in
> January....then February, then maybe March, then he disappeared.)

Yes, we focus on having a prefixed install. And to avoid any
confusion, or make it even worse hereafter, in *development* we have
*extremely* buggy beta versions of a prefixed install, which are *no way
of even being close to ready for users*. Please note, a huge disclaimer
applies here: it's *NOT* useable at all. What's currently in gentoo,
and in installers, is *not* a prefixed version.

> I appreciate the labels+definitions for the alternatives. That makes
> it loads easier to refer to things and have some reasonable hope that
> others will understand what you're referring to.

I realise that this page might be a bit vague. In the first place it is
meant for developers active in this field, and interested users.

> > The page should fill a gap in the explanation of our road ahead, and my
> Actually, the page quite admirably explained the past, the
> alternatives, and why the present focus is (rightly) turning towards
> prefixed efforts. The future ("road ahead") wasn't really explicitly

I realised that when I re-read it. I'll try to improve it anyway.

> mentioned. I'd welcome a tentative future timeline at the bottom of
> the doc, if possible. The common question outside of the core dev
> team seems to be "When will there be something that works that I can
> use [and/or contribute to]?"

This is actually a question, which's answer is much larger than just me
or the team members. It requires the whole community to agree on a
rather large change into their core product: Portage. You can consider
this as a road towards a huge GLEP. Pieces that I write might be
reusable, in such document, to make it a full story, including some
experimental, but mature results. It's not only our work, far from.
Without the help of some Portage guys, we'd never got here I think.

Since we're all busy, and progress usually comes with little bumps, I'm
hestitant to give any predictions on time frames. I don't oversee the
whole picture yet, so I don't want to give any release dates.

Thanks for your time to read it and comment upon.


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

> We are *not* prefixed. This a page on what we would *like* to be,
> somehow.

Ok, I get it now. Thanks for clarifying that.

> > mentioned. I'd welcome a tentative future timeline at the bottom of
> > the doc, if possible. The common question outside of the core dev
> > team seems to be "When will there be something that works that I can
> > use [and/or contribute to]?"
>
> This is actually a question, which's answer is much larger than just me
> or the team members. It requires the whole community to agree on a
> rather large change into their core product: Portage. You can consider
> this as a road towards a huge GLEP. Pieces that I write might be
> reusable, in such document, to make it a full story, including some
> experimental, but mature results. It's not only our work, far from.
> Without the help of some Portage guys, we'd never got here I think.
>
> Since we're all busy, and progress usually comes with little bumps, I'm
> hestitant to give any predictions on time frames. I don't oversee the
> whole picture yet, so I don't want to give any release dates.

I should have explicitly stated that I wasn't looking for dates
per-se. More like a list of "here is the milestones that have to
happen."

For example (realizing that this is completely fictional as I'm just
on onlooker [but maybe sort of real-sounding], just to illustrate):

1) Portage guys have to finalize a prefix-aware portage in ~ (latest
indications point to this happening by quarter X year Y)
2) Portage tree must be updated for prefix
3) Concurrent to #2 our devs will release an installer that uses an
overlay tree (ambitious users can jump in here)
4) Big showstoppers that have issues are addressed
5) Portage guys stabilize the prefix-aware portage, tree is all updated
6) Beta installer created and released using the real portage tree
(beta-friendly users can jump in here) (This step will not reached
until issue ABC is also addressed or the century XYZ is reached,
whichever is later)
etc. etc.

If you have something like that, a lot of questions can be answered by
"we can do that as soon as we reach step X."

> Thanks for your time to read it and comment upon.

No problem. I can't wait until the project reaches a point where _I_
can actually contribute in a real way.

I did notice one typo: "...at the moment clumpsy" --> "...at the moment clumsy"

~ Nathan

--
gentoo-osx@gentoo.org mailing list

On 12-12-2005 11:21:32 -0700, Nathan wrote:
[snipped milestone list]
>
> If you have something like that, a lot of questions can be answered by
> "we can do that as soon as we reach step X."

Ok, this really is a useful suggestion. I didn't think of that. I'll
try to outline some milestones, if I can think of any ;)

> > Thanks for your time to read it and comment upon.
>
> No problem. I can't wait until the project reaches a point where _I_
> can actually contribute in a real way.

It might sound, but also I can't wait for that moment to happen.

> I did notice one typo: "...at the moment clumpsy" --> "...at the moment clumsy"

gotcha. Changed it. See next post to this list.


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

After some comments sent both off and onlist, I made some changes. I
plan to make more extensions. I figured that the interest in this
document was larger than I initially expected, hence for convenience, I
will supply diffs of changes I make to the list.

On 12-12-2005 10:01:28 +0100, Grobian wrote:
> Anywayz, I wrote a new page yesterday:
> http://www.gentoo.org/proj/en/gentoo-alt/macos/targets.xml


--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead

Small rewording change attached.

--
Fabian Groffen
Gentoo for Mac OS X Project -- Interim Lead

Hi,

I just wanted to open for discussion another idea I've got to solve the
problem of having to update a system with a fixed set of pre-installed
components, aka the "Gentoo for OSX" problem.
I would like to avoid the prefixed approach (which seems to need changes
in the system software, i.e. the Portage system).
Instead i would like to solve the problem on a lower level.

A (Linux) LiveCD distribution faces a similar problem, because you have a
amount of static / read only content on your CD, while you are still able
to install packages from the internet.
Such Live CDs solve this by the introduction of "read-write" mounted
CD-ROM devices, using a mechanism called a "union file system". Such a
Union file system (unionfs) provides a unified view from a couple of
source trees to a result tree. THis applies to all file system accesses,
i.e. read, write, list directory a.s.o..

A unionfs is supported natively by MacOSX.

A problem of such an approach is that mounted file systems are visible
globally. A better solution would be a file system which is only visible
in a local environment.
Unfortunately real user space per process file systems are not yet
available on Unix like sstems, including Linux and Darwin / MacOSX.

For Linux there exist some work to implement such functionality, e.g. in
the Plasticfs project on Sourceforge. It seems to be implemented as some
kind of clever LD_PRELOAD hack.

Regards
Dirk


--
gentoo-osx@gentoo.org mailing list

On Tue, 13 Dec 2005, Dirk Schönberger wrote:

> A problem of such an approach is that mounted file systems are visible
> globally. A better solution would be a file system which is only visible
> in a local environment. Unfortunately real user space per process file
> systems are not yet available on Unix like sstems, including Linux and
> Darwin / MacOSX.
>

There has been work done on the linux kernel to allow private mounts.

http://groups.google.com.au/group/linux.kernel/browse_frm/thread/62624da3dd5b31bc/bf3ca193c4dab012

The shared subtree patch is probably sufficient?

http://groups.google.com.au/group/linux.kernel/browse_frm/thread/392c6d4e048ea3e8/46daf8d6e2c714cb

-f

>
> On Tue, 13 Dec 2005, Dirk Schönberger wrote:
>
>> A problem of such an approach is that mounted file systems are visible
>> globally. A better solution would be a file system which is only visible
>> in a local environment. Unfortunately real user space per process file
>> systems are not yet available on Unix like sstems, including Linux and
>> Darwin / MacOSX.
>>
>
> There has been work done on the linux kernel to allow private mounts.
>

Unfortunately we are still on vanilla Mac OS X / Darwin, not some
experimental Linux kernel ;)

Regards
Dirk
--
gentoo-osx@gentoo.org mailing list

Indeed. User migration will be an interesting exercise. I think it's
more or less unavoidable to recompile everything for the prefixed
install. Any ideas on how to do this are welcome. I guess the most
trival one is to copy the world file, unmerge everything, and then
reemerge everything from the copied world file. I guess this is not a
good solution...

On 14-12-2005 20:11:18 +0100, Marcin Gabrowski wrote:
> First, The way of contribute Gentoo Portage with prefixed path, I think
> that is very good idea.
>
> I think also, that not bad, choose will be release converter for
> those users
> which has Getoo for OSX to Gentoo Portage for OSX.
> Some how shell script or maybe good HowTo, which shows, how to
> migrate to present state.
>
> We should find a simple way to migrate. Users need it.
> Maybe the simplest deinstall all packages which bootstrap installed
> is the best solution.
>
> gaber
>
> --
> gg: 606 ripe: mg3051 jid: gaber/gentoo.pl
>
>



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

On 14-12-2005 20:12:06 +0100, Marcin Gabrowski wrote:
> >>There has been work done on the linux kernel to allow private mounts.
> >>
> >Unfortunately we are still on vanilla Mac OS X / Darwin, not some
> >experimental Linux kernel ;)
> >
> Look in the future, iPods as mobile mounting devices with Gentoo.
> Such geekness :>

I don't think that's geek... It starts to get geeky when you run Linux
on your iPod so only 60% of its functions work and still call it cool.
:)

I agree with Dirk that the capabilities of the Linux kernel are not
really of interest for this discussion.


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

On 14-12-2005 21:18:46 +0100, Marcin Gabrowski wrote:
> Looknig at DarwinPorts, I dont see any other way to obtain what we want.
> Prefixed installation makes changes eg path in configfiles, libs.
> I think that document, which tells users what should be done, which
> files
> move, how move and where move is require.
>
> We should also remember that users that uses GetooForOSX didnt have
> to be
> LinuxUser before. For them location of some files dont go without
> saying.

This is very well possible.

> Thinking in prefixed way, we can say that DeveloperTools/XCode doesnt
> be needed
> in some way. I try think about simple bootstrap for Portage which makes
> independend of system tools

Unfortunately we need some system headers to be installed, which are
only supplied by Xcode. So even though the dependency on Xcode is
minimal, currently you still need it, and they need to match the kernel.

> Btw, what abuot draf skel of location dirs, files, configs of prefix?
> What do u think about /opt/gentoo/?

We use /Library/Gentoo now, because that's more OSXier than /opt.
Inside this dir, everything will be in the same place as on a Linux
system.


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

> > Btw, what abuot draf skel of location dirs, files, configs of prefix?
> > What do u think about /opt/gentoo/?

> We use /Library/Gentoo now, because that's more OSXier than /opt.
> Inside this dir, everything will be in the same place as on a Linux
> system.

I don't really understand MacOSX file system hierarchy, but isn't /Library
user specific?
For real system level stuff there should also exist /System/Library.

Further on, I think Gentoo is more than a stand alone system, because it
installs other standalone applications.
This seems to be some mismatch.

Reagdrs
Dirk




--
gentoo-osx@gentoo.org mailing list

On 12/14/05, Dirk Schönberger <dirk.schoenberger@sz-online.de> wrote:
> > > Btw, what abuot draf skel of location dirs, files, configs of prefix?
> > > What do u think about /opt/gentoo/?
>
> > We use /Library/Gentoo now, because that's more OSXier than /opt.
> > Inside this dir, everything will be in the same place as on a Linux
> > system.
>
> I don't really understand MacOSX file system hierarchy, but isn't /Library
> user specific?
> For real system level stuff there should also exist /System/Library.

No, /Library is a system dir.

> Further on, I think Gentoo is more than a stand alone system, because it
> installs other standalone applications.
> This seems to be some mismatch.

I don't understand what you're trying to say here.

~ Nathan

--
gentoo-osx@gentoo.org mailing list

> > Further on, I think Gentoo is more than a stand alone system, because it
> > installs other standalone applications.
> > This seems to be some mismatch.

> I don't understand what you're trying to say here.

If I underood this correctly, the idea is to use /Library/Gentoo as a prefix
for the prospective prefixed install.
But the packages which should be installed don't really belong to Gentoo, it
merely works as some kind of installer.
So I don't think /Library/Gentoo is really appropriate.

Regards
Dirk



--
gentoo-osx@gentoo.org mailing list

On 14-12-2005 22:22:21 +0100, Dirk Schnberger wrote:
> > > Btw, what abuot draf skel of location dirs, files, configs of prefix?
> > > What do u think about /opt/gentoo/?
>
> > We use /Library/Gentoo now, because that's more OSXier than /opt.
> > Inside this dir, everything will be in the same place as on a Linux
> > system.
>
> I don't really understand MacOSX file system hierarchy, but isn't /Library
> user specific?
> For real system level stuff there should also exist /System/Library.

User specific will be for sure ~/Library. I guess /Library is for apps,
while /System/Library is for system components (duh). Looking into the
dirs, it makes sense somehow. Anything in /System you shouldn't touch,
IMHO. Probably someone else knows it better than me. Please enlighten
us.

> Further on, I think Gentoo is more than a stand alone system, because it
> installs other standalone applications.
> This seems to be some mismatch.

?
Elaborate on that please.


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

On 14-12-2005 22:29:36 +0100, Dirk Schnberger wrote:
> > > Further on, I think Gentoo is more than a stand alone system, because it
> > > installs other standalone applications.
> > > This seems to be some mismatch.
>
> > I don't understand what you're trying to say here.
>
> If I underood this correctly, the idea is to use /Library/Gentoo as a prefix
> for the prospective prefixed install.
> But the packages which should be installed don't really belong to Gentoo, it
> merely works as some kind of installer.
> So I don't think /Library/Gentoo is really appropriate.

Ok.
To be honest, I don't really care about the name, but I don't feel like
having huge discussions about it either. We just chose something more
sexy than /sw. Besides that, having chosen a default, doesn't mean you
need to use it. We could name it like
/Library/GentooPortageInstalledPackages, but that really looks ugly in
your paths. Luckly there is shell completion, but it still is a bit too
ugly to me.
Finally, this is just a minor side issue, that I feel is completely
irrelevant regarding the state of the project.


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

On 12/14/05, Grobian <grobian@gentoo.org> wrote:
> On 14-12-2005 22:29:36 +0100, Dirk Schnberger wrote:
> > > > Further on, I think Gentoo is more than a stand alone system, because it
> > > > installs other standalone applications.
> > > > This seems to be some mismatch.
> >
> > > I don't understand what you're trying to say here.
> >
> > If I underood this correctly, the idea is to use /Library/Gentoo as a prefix
> > for the prospective prefixed install.
> > But the packages which should be installed don't really belong to Gentoo, it
> > merely works as some kind of installer.
> > So I don't think /Library/Gentoo is really appropriate.
>
> Ok.
> To be honest, I don't really care about the name, but I don't feel like
> having huge discussions about it either. We just chose something more
> sexy than /sw. Besides that, having chosen a default, doesn't mean you
> need to use it. We could name it like
> /Library/GentooPortageInstalledPackages, but that really looks ugly in
> your paths. Luckly there is shell completion, but it still is a bit too
> ugly to me.
> Finally, this is just a minor side issue, that I feel is completely
> irrelevant regarding the state of the project.

Amen.

--
gentoo-osx@gentoo.org mailing list

> To be honest, I don't really care about the name, but I don't feel like
> having huge discussions about it either. We just chose something more
> sexy than /sw. Besides that, having chosen a default, doesn't mean you
> need to use it. We could name it like
> /Library/GentooPortageInstalledPackages, but that really looks ugly in
> your paths. Luckly there is shell completion, but it still is a bit too
> ugly to me.
> Finally, this is just a minor side issue, that I feel is completely
> irrelevant regarding the state of the project.

Sorry to be obnoxious, but I think the topic is rather relevant, at least
IMHO.
Basically you (Gentoo for OSX) have the problem, that you have to work on a
system
which is not really prepared to work with a system like Gentoo.

The MacOSX file system hierarchy is a mix of two subsystems.

First there is its Unix heritage, i.e. the /usr, /dev, /etc, /var hierarchy,
Second there is more modern "MacOS usability system" (for lack of better
words).
The second system has whole other assumptions about what is in a systerm.
Basically you have a set of applications
(as app folders), in the /Applications folder, and components which play a
support role to these applications, namely the
/Libary, ~/Library, /System/Library hierarchy.

Additionally at least the Mac default system is implemented so that the Unix
hierarchy is hidden, i.e. not visible from the GUI system
(finder)

Conceptionally Gentoo belongs more to the Unix hierarchy, basically it tries
to supplant a the static Mac Unix subsystem by a more dynamic,
package managed system. Most (or at least currently all) of these packages
are not suitable to a GUI system.

So they should not be part of the second file system items.

I think Gentoo should at least try to be a correct citizen on a Mac system,
this includes it should honour the system assumptions.

Regards
Dirk




--
gentoo-osx@gentoo.org mailing list

On 12/14/05, Dirk Schönberger <dirk.schoenberger@sz-online.de> wrote:
> > To be honest, I don't really care about the name, but I don't feel like
> > having huge discussions about it either. We just chose something more
> > sexy than /sw. Besides that, having chosen a default, doesn't mean you
> > need to use it. We could name it like
> > /Library/GentooPortageInstalledPackages, but that really looks ugly in
> > your paths. Luckly there is shell completion, but it still is a bit too
> > ugly to me.
> > Finally, this is just a minor side issue, that I feel is completely
> > irrelevant regarding the state of the project.
>
> Sorry to be obnoxious, but I think the topic is rather relevant, at least
> IMHO.
> Basically you (Gentoo for OSX) have the problem, that you have to work on a
> system
> which is not really prepared to work with a system like Gentoo.
>
> The MacOSX file system hierarchy is a mix of two subsystems.
>
> First there is its Unix heritage, i.e. the /usr, /dev, /etc, /var hierarchy,
> Second there is more modern "MacOS usability system" (for lack of better
> words).
> The second system has whole other assumptions about what is in a systerm.
> Basically you have a set of applications
> (as app folders), in the /Applications folder, and components which play a
> support role to these applications, namely the
> /Libary, ~/Library, /System/Library hierarchy.
>
> Additionally at least the Mac default system is implemented so that the Unix
> hierarchy is hidden, i.e. not visible from the GUI system
> (finder)
>
> Conceptionally Gentoo belongs more to the Unix hierarchy, basically it tries
> to supplant a the static Mac Unix subsystem by a more dynamic,
> package managed system. Most (or at least currently all) of these packages
> are not suitable to a GUI system.
>
> So they should not be part of the second file system items.
>
> I think Gentoo should at least try to be a correct citizen on a Mac system,
> this includes it should honour the system assumptions.
>
> Regards
> Dirk

You're getting rather stuck on a tiny little issue for a system that
doesn't really exist yet. It's just a string! Rest assured that
before the final product is released the "correct" default path will
be selected. Until then, the system doesn't exist, and when it does,
you should be able to set it to whatever you want anyway, whethere
that's /Library/Gentoo, /opt/g2, or
/Volumes/usbdrive/.hidden/far_away/big/long/path/to/gentoo

~ Nathan

--
gentoo-osx@gentoo.org mailing list

> You're getting rather stuck on a tiny little issue for a system that
> doesn't really exist yet. It's just a string! Rest assured that
> before the final product is released the "correct" default path will
> be selected.

The problem is that I am not sure if such thing as a "correct" default path
even exist.
IMHO the whole prefix based approach is a crutch which solves the problem in
the wrong place.
If you want to keep a "pure" Unix system hierarchy (which is my intention)
you should try to keep all elements on the place
where they are expected. This means no additional appendizes just because it
is technically opportune.

If I wanted a unclean file system, I could change to DarwinPorts or Fink ;)

Regards
Dirk

--
gentoo-osx@gentoo.org mailing list

> If you want to keep a "pure" Unix system hierarchy (which is my intention)
> you should try to keep all elements on the place
> where they are expected. This means no additional appendizes just because
it
> is technically opportune.

> If I wanted a unclean file system, I could change to DarwinPorts or Fink
;)

Just to show what I mean:

My idea is to implement a better MacOS GUI integration of Gentoo installed
tools.
This means real app folders which contain the actual GUI and which call the
correct Unix executables.
These packages could either directly packages in ebuilds, or they could be
external packages which are dependent on the actuall application.
I.e. something like

depends on
ghostscript-gui <----- ghostscript

In a non-prefixed approach, I can be sure that there will exist an
executable /usr/bin/gs, which I can call.
What I am to do in a prefixed system? Hope that the users did not forget to
call setenv-gentoo on bootup?
Start a local shell which calls setenv-gentoo, which maybe itself be
somewhere on
/Volumes/usbdrive/.hidden/far_away/big/long/path/to/gentoo/bin/setenv-gentoo
And do a exec "/bin/sh gs"? This sounds like a rather big security problem
to me, because nothing stops any malware to change things like
the path variable.

Regards
Dirk




--
gentoo-osx@gentoo.org mailing list

On 12/14/05, Dirk Schönberger <dirk.schoenberger@sz-online.de> wrote:
> > If you want to keep a "pure" Unix system hierarchy (which is my intention)
> > you should try to keep all elements on the place
> > where they are expected. This means no additional appendizes just because
> it
> > is technically opportune.
>
> > If I wanted a unclean file system, I could change to DarwinPorts or Fink
> ;)
>
> Just to show what I mean:
>
> My idea is to implement a better MacOS GUI integration of Gentoo installed
> tools.
> This means real app folders which contain the actual GUI and which call the
> correct Unix executables.
> These packages could either directly packages in ebuilds, or they could be
> external packages which are dependent on the actuall application.
> I.e. something like
>
> depends on
> ghostscript-gui <----- ghostscript
>
> In a non-prefixed approach, I can be sure that there will exist an
> executable /usr/bin/gs, which I can call.
> What I am to do in a prefixed system? Hope that the users did not forget to
> call setenv-gentoo on bootup?
> Start a local shell which calls setenv-gentoo, which maybe itself be
> somewhere on
> /Volumes/usbdrive/.hidden/far_away/big/long/path/to/gentoo/bin/setenv-gentoo
> And do a exec "/bin/sh gs"? This sounds like a rather big security problem
> to me, because nothing stops any malware to change things like
> the path variable.
>
> Regards
> Dirk

Sounds like you should read:

http://www.gentoo.org/proj/en/gentoo-alt/macos/targets.xml

If I'm not mistaken, you want the "Darwin Portage"-type setup. If you
read the "Road Map" section, you will see that it's been decided to
head in the "Gentoo Portage for Mac OS X" direction (i.e. prefix).

I'm sure that no one would object if you decided to head up your own
"Darwin Portage" project, as there would be some overlap.

~ Nathan

--
gentoo-osx@gentoo.org mailing list

> Sounds like you should read:

> http://www.gentoo.org/proj/en/gentoo-alt/macos/targets.xml

> If I'm not mistaken, you want the "Darwin Portage"-type setup. If you
> read the "Road Map" section, you will see that it's been decided to
> head in the "Gentoo Portage for Mac OS X" direction (i.e. prefix).

> I'm sure that no one would object if you decided to head up your own
> "Darwin Portage" project, as there would be some overlap.

I don't think I have the time or will to implement my own Gentoo subproject.
If a prefix based approach is implemented, I think I will have to switch to
Fink or DarwinPorts, where at least exist a _fixed_ prefix, where I can
depend upon.
I would regret this, because I still think that Gentoo in its current form
is the more "pure" approach.
My ideal would still be to implement a thing like a unionfs which allows
clean overriding of system level libraries.

Regards
Dirk




--
gentoo-osx@gentoo.org mailing list