[gentoo-osx] New document: Project targets

[gentoo-osx] New document: Project targets

[Grobian]

Hi gang,

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

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.


[1] thess are hints, not a real requests.[2]
[2] remark included for quoteability reasons.

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

Re: [gentoo-osx] New document: Project targets

[Nathan]

> 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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Nathan]

> 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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

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

[-- Attachment #2: changes.diff --]
[-- Type: text/plain, Size: 4159 bytes --]

--- targets.xml
+++ targets.xml
@@ -71,9 +71,14 @@
           the first case, the package manager is responsible for
           building the (core) system, while in the latter case, the
           package manager builds on top of an existing system to enhance
-          it.  Gentoo Portage is the primary package manager on its
-          GNU/Linux distribution, and as such, the Gentoo Portage tree
-          matches this goal.
+          it.  Please note that this is by no means meant as a formal
+          definition of the general concept "package manager".  Within
+          this document it is used as entity that is natively
+          responsible for managing software packages on the OS it works
+          on.  Effectively, this means that Gentoo Portage is not the
+          primary package manager on Mac OS X.  Gentoo Portage is the
+          primary package manager on its GNU/Linux distribution, and as
+          such, the Gentoo Portage tree matches this goal.
         </p>
 
       </body>
@@ -104,7 +109,9 @@
           <li>
             Because Portage installs next to the OS, in the same
             directories, no fancy path settings are necessary,
-            everything is installed in default places.
+            everything is installed in default places.  Note that the
+            relatively large overlap of the Gentoo Linux file system
+            layout and Darwin's one, causes this advantage.
           </li>
           <li>
             Portage can use tools provided by the OS, this avoids
@@ -113,7 +120,11 @@
           <li>
             Once a tool provided by the OS is outdated, or not recent
             enough, Portage cannot update it without overwriting the OS
-            provided one.
+            provided one.  Note that this doesn't necessarily have to be
+            a drawback, as from a progressive viewpoint this allows more
+            control over the system, e.g. breaking a possible lock-in by
+            the OS vendor.  In that sense, also downgrading a package
+            version applies.
           </li>
           <li>
             The vendor of the OS that provides a tool, might have
@@ -126,8 +137,8 @@
             Because Portage installs its files next to where the OS
             installs them, the primary package manager of the OS might
             install a package and overwrite files provided by Portage.
-            It is hard (if not impossible) for Portage to figure this
-            out and execute correcting actions.
+            It might be hard for Portage to figure this out in time, and
+            possibly execute correcting actions.
           </li>
         </ul>
 
@@ -170,9 +181,9 @@
             will happen.
           </li>
           <li>
-            Since Portage will be the one to decide what is installed
-            and what not, it will be possible to leave out much unwanted
-            software.
+            Since Portage will be the one to decide how and when the OS
+            and extra tools are installed, it will be possible to leave
+            out much unwanted software.
           </li>
           <li>
             Building a system from scratch requires skills, usually not
@@ -182,8 +193,9 @@
           </li>
           <li>
             A tree that encodes the logic and assumptions of the Darwin
-            software packages needs to be built, which more or less
-            throws away the efforts of the Gentoo Portage tree.
+            software packages needs to be built.  The question remains
+            how much of the efforts of the Gentoo Portage tree can be
+            reused for this.
           </li>
         </ul>
 
@@ -322,7 +334,7 @@
         </p>
         <p>
           Prefix support in Portage has reached an alpha level in the
-          development branches.  This -- at the moment clumpsy -- but
+          development branches.  This -- at the moment clumsy -- but
           more or less usuable product is used to find out what changes
           will be necessary to the Gentoo Portage tree.  The major work
           of making Portage prefix aware has been done, and the

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Small rewording change attached.

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

[-- Attachment #2: changes.diff --]
[-- Type: text/plain, Size: 583 bytes --]

--- targets.xml
+++ targets.xml
@@ -298,8 +298,9 @@
         </p>
 
         <p>
-          Because "Darwin Portage" is not suitable for a mainstream user
-          distribution, it was chosen to change the direction towards
+          Because "Darwin Portage" requires efforts towards a tree to be
+          made, and because it is a rather big difference from a regular
+          Mac OS X system, it was chosen to change the direction towards
           "Gentoo Portage for Mac OS X", to enable Gentoo's Mac OS X
           project to continue and innovate again.
         </p>

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

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

Re: [gentoo-osx] New document: Project targets

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 715 bytes --]


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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

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

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-12, at 19:21, Nathan wrote:

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



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-14, at 10:10, 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 ;)
>
Look in the future, iPods as mobile mounting devices with Gentoo.
Such geekness :>

gaber

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-14, at 10:10, 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 ;)
>
Look in the future, iPods as mobile mounting devices with Gentoo.
Such geekness :>

gaber

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-14, at 20:25, Grobian wrote:
>> 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.
> :)
Hum, I've got dualboot ipod, with iPodLinux and AppleOS.
ipodlinux is interested as "another user experience", but lack such
functionality as working Poweroff, it makes unuseable for me now.
I see progress at this project. Give it time, and will be good. :-)

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

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-14, at 20:22, Grobian wrote:
>> We should find a simple way to migrate. Users need it.
>> Maybe the simplest deinstall all packages which bootstrap installed
>> is the best solution.
> 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...
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.

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

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

gaber

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

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

Re: [gentoo-osx] New document: Project targets

[Nathan]

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

Re: [gentoo-osx] New document: Project targets

[Nathan]

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

> 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

Re: [gentoo-osx] New document: Project targets

[Nathan]

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

> 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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

> 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

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-14, at 23:01, Dirk Schönberger wrote:
> The MacOSX file system hierarchy is a mix of two subsystems.
I think that proper way is make variable PREFIX or ROOT gives
as configuriable.

Adding coment in make.conf that for unix-way it should be in eg.:
- /opt/gentoo or
- /usr/gentoo or
- /usr/local/gentoo/ or
~/gentoo/

but for OSX way should be in eg.:
- (~)/Library/gentoo or
- /System/Library/.

Default may second one.

Second is better when we thinking on eg. iBackup, which gives
users simple method to eg. click backup GentooPortage or part of one.

Visibility in Finder for Users is also _very important_.

gaber

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Nathan]

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

> 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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

> > The MacOSX file system hierarchy is a mix of two subsystems.
> I think that proper way is make variable PREFIX or ROOT gives
> as configuriable.

> Adding coment in make.conf that for unix-way it should be in eg.:
> - /opt/gentoo or
>- /usr/gentoo or
> - /usr/local/gentoo/ or
> ~/gentoo/

> but for OSX way should be in eg.:
> - (~)/Library/gentoo or
> - /System/Library/.

> Default may second one.

Problem is that one folder is not enough, because you still need access to
the "classic" Unix  hierarchy (/usr/bin, /bin, /sbin).
Perhaps you also want to use two or more prefixes.

The question which executable to start begins to look like path resolution
in a Unix shell, which I don'Ät really wan to implement
in a simple frontend script.

Regards
Dirk


-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-15, at 00:42, Dirk Schönberger wrote:

>>> The MacOSX file system hierarchy is a mix of two subsystems.
>> I think that proper way is make variable PREFIX or ROOT gives
>> as configuriable.
> Problem is that one folder is not enough, because you still need  
> access to
> the "classic" Unix  hierarchy (/usr/bin, /bin, /sbin).
> Perhaps you also want to use two or more prefixes.
Hm.. but why? I'd use symlinks eg. /usr/bin/wc -> /opt/gentoo/bin/wc,  
what resolves those problems.

> The question which executable to start begins to look like path  
> resolution
> in a Unix shell, which I don'Ät really wan to implement
> in a simple frontend script.
Global envioment variable eg. PREFIX ponting to /opt/gentoo/ in  
shellscripts?

What do You think about it? And why not? :-)

gaber

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Grobian]

On 14-12-2005 23:33:39 +0100, Dirk Schnberger wrote:
> > 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.

With this puristic view you should join Finn Thain and go for what he
calls Gentoo OpenDarwin.  Only that solution allows for what you want,
without having a progressive system.

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

Understandable, but unavoidable.


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

Re: [gentoo-osx] New document: Project targets

[Grobian]

On 15-12-2005 00:36:31 +0100, Dirk Schnberger wrote:
> > 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.

It's a matter of priorities, and the prefix support is higer in the list
than Darwin Portage.

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

two things:
1) if (and only if) the Gentoo for OS X installer allows you to set the
   prefix, then nothing prevents you from setting it to /, IMHO,
   resulting in the situation as now.
2) if the Gentoo for OS X installer doesn't allows you to set it, the
   prefix location will in practise be as fixed as for DarwinPorts and
   Fink.

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

If you happen to find out how to do this properly, I would be more than
willing to see whether it is possible to simply use an offset to install
in, but not changing the paths within this offset (like a chroot jail),
such that the packages in your union mount look for things in the main
file system (i.e. "/").  Since your previous results have proven to be
interesting, but not fully covering (eg. global union mount), in the
meanwhile we keep on working on the prefix.


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

Re: [gentoo-osx] New document: Project targets

[Grobian]

On 15-12-2005 01:35:23 +0100, Marcin Gabrowski wrote:
> Hello,
> 
> On 2005-12-15, at 00:42, Dirk Schönberger wrote:
> 
> >>>The MacOSX file system hierarchy is a mix of two subsystems.
> >>I think that proper way is make variable PREFIX or ROOT gives
> >>as configuriable.
> >Problem is that one folder is not enough, because you still need  
> >access to
> >the "classic" Unix  hierarchy (/usr/bin, /bin, /sbin).
> >Perhaps you also want to use two or more prefixes.
> Hm.. but why? I'd use symlinks eg. /usr/bin/wc -> /opt/gentoo/bin/wc,  
> what resolves those problems.

Or what about a Framework?

> >The question which executable to start begins to look like path  
> >resolution
> >in a Unix shell, which I don'Ät really wan to implement
> >in a simple frontend script.

Is it really possible to find any executable without path resolution?
Only ./myapp doesn't require the shell to use the $PATH variable, but
does use the current (absolute) path ($CWD) in order to start the myapp
binary.

Using "#!/usr/bin/env perl" in a script instead of "#!/usr/bin/perl"
allows perl to be in any location in the path environment.


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

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

>> >Problem is that one folder is not enough, because you still need
>> >access to
>> >the "classic" Unix  hierarchy (/usr/bin, /bin, /sbin).
>> >Perhaps you also want to use two or more prefixes.
>> Hm.. but why? I'd use symlinks eg. /usr/bin/wc -> /opt/gentoo/bin/wc,
>> what resolves those problems.
>

This may be a problem if /usr/bin/wc is already an executable provided by
MacOSX

> Or what about a Framework?

Care to elaborate?

> Is it really possible to find any executable without path resolution?
> Only ./myapp doesn't require the shell to use the $PATH variable, but
> does use the current (absolute) path ($CWD) in order to start the myapp
> binary.

You still can do an explicit /usr/bin/wc

>
> Using "#!/usr/bin/env perl" in a script instead of "#!/usr/bin/perl"
> allows perl to be in any location in the path environment.
>

I am not really interested in finding perl, but instead the executable I
want to call (/usr/bin/wc in this case)
Besides, if I do a "#!/usr/bin/env perl", I may find the MacOSX provided
Perl, not the Perl I installed via Gentoo.
Somehow defeats the purpose, doesn't it?

Regards
Dirk

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

>> 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.
>
> two things:
> 1) if (and only if) the Gentoo for OS X installer allows you to set the
>    prefix, then nothing prevents you from setting it to /, IMHO,
>    resulting in the situation as now.
> 2) if the Gentoo for OS X installer doesn't allows you to set it, the
>    prefix location will in practise be as fixed as for DarwinPorts and
>    Fink.
>

Not really.
If 1) is implemented, I cannot be sure that all users have / as their
prefix, which means all packages which are dependent upon others (like in
my frontend idea) have to add additional logic to actually find the items
they depend upon. This means more work in implementing and maintaining.
If 2) is implemented, I am not better than in DarwinPorts, but in
DarwinPorts the system is implemented and works. Portage would be in a
state of adaption for a longer time.

> If you happen to find out how to do this properly, I would be more than
> willing to see whether it is possible to simply use an offset to install
> in, but not changing the paths within this offset (like a chroot jail),
> such that the packages in your union mount look for things in the main
> file system (i.e. "/").  Since your previous results have proven to be
> interesting, but not fully covering (eg. global union mount), in the
> meanwhile we keep on working on the prefix.

Fine with me.

Regards
Dirk

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-15, at 09:27, Dirk Schönberger wrote:
>>> Hm.. but why? I'd use symlinks eg. /usr/bin/wc -> /opt/gentoo/bin/ 
>>> wc,
>>> what resolves those problems.
>>
>
> This may be a problem if /usr/bin/wc is already an executable  
> provided by
> MacOSX
>
>> Or what about a Framework?
>
> Care to elaborate?

Linking /usr/bin/wc into PREFIX root of Gentoo Portage, we dont hurt  
OSX.

> I am not really interested in finding perl, but instead the  
> executable I
> want to call (/usr/bin/wc in this case)
> Besides, if I do a "#!/usr/bin/env perl", I may find the MacOSX  
> provided
> Perl, not the Perl I installed via Gentoo.
> Somehow defeats the purpose, doesn't it?

Maybe it's time to look at DarwinPorts, and makes it better. :-)

gaber
-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

>>>> Hm.. but why? I'd use symlinks eg. /usr/bin/wc -> /opt/gentoo/bin/
>>>> wc,
>>>> what resolves those problems.
>>>
>>
>> This may be a problem if /usr/bin/wc is already an executable
>> provided by
>> MacOSX
>>
>>> Or what about a Framework?
>>
>> Care to elaborate?
>
> Linking /usr/bin/wc into PREFIX root of Gentoo Portage, we dont hurt
> OSX.

if /usr/bin/wc was not created by Apple/MacOSX, there is no need to
actually link to /opt/portage (or wherever). This already works and is the
status quo (prefix-less Gentoo).
If /usr/bin/wc was created by Apple/MacOSX, by creating the link you
override system behaviour, and therefore hurt OSX.

Or do I miss something obvious?

Regards
Dirk

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Marcin Gabrowski]

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

Hello,

On 2005-12-15, at 10:47, Dirk Schönberger wrote:
>> Linking /usr/bin/wc into PREFIX root of Gentoo Portage, we dont hurt
>> OSX.
>
> if /usr/bin/wc was not created by Apple/MacOSX, there is no need to
> actually link to /opt/portage (or wherever). This already works and  
> is the
> status quo (prefix-less Gentoo).
/usr/bin/wc is provided in OSX by default. But, nevermind. Exists  
important
other things in this moment.

What's about wiki for saving draft of assumptions?

gaber

-- 
gg: 606 ripe: mg3051 jid: gaber/gentoo.pl



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-osx] New document: Project targets

[Grobian]

On 15-12-2005 09:27:50 +0100, Dirk Schönberger wrote:
> > Is it really possible to find any executable without path resolution?
> > Only ./myapp doesn't require the shell to use the $PATH variable, but
> > does use the current (absolute) path ($CWD) in order to start the myapp
> > binary.
> 
> You still can do an explicit /usr/bin/wc

Eh yeah?  I didn't understand your initial comment.  Your absolute
example is equal to my ./ example.

> > Using "#!/usr/bin/env perl" in a script instead of "#!/usr/bin/perl"
> > allows perl to be in any location in the path environment.
> >
> 
> I am not really interested in finding perl, but instead the executable I
> want to call (/usr/bin/wc in this case)

/usr/bin/env wc

> Besides, if I do a "#!/usr/bin/env perl", I may find the MacOSX provided
> Perl, not the Perl I installed via Gentoo.
> Somehow defeats the purpose, doesn't it?

Not really, because /usr/bin/env does a path resolution.  This means
that the first binary it finds that matches is executed, like a shell
does that.  If you setup your paths appropriately, scripts don't need to
know where wc, perl, awk or whatever exactly remain.


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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

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

> If you happen to find out how to do this properly, I would be more than
> willing to see whether it is possible to simply use an offset to install
> in, but not changing the paths within this offset (like a chroot jail),
> such that the packages in your union mount look for things in the main
> file system (i.e. "/").  Since your previous results have proven to be
> interesting, but not fully covering (eg. global union mount), in the
> meanwhile we keep on working on the prefix.

After googling a little around, the combination of chroot/jail and union
mounts seems to be a accepted solution to the global union mount problem.
It is used for most of the interesting virtualization / virtual server
setups.

What's missing is how to access such a jail from a finder started
application ;)

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

Re: [gentoo-osx] New document: Project targets

[Grobian]

On 15-12-2005 16:02:49 +0100, Dirk Schönberger wrote:
> After googling a little around, the combination of chroot/jail and union
> mounts seems to be a accepted solution to the global union mount problem.
> It is used for most of the interesting virtualization / virtual server
> setups.
> 
> What's missing is how to access such a jail from a finder started
> application ;)

Somehow you have to enter the matr^Wchroot jail.  I don't think you can
do this from the Finder, so you would end up with a folder with script
files I think, which the Finder can access.


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

Re: [gentoo-osx] New document: Project targets

[Grobian]

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

I added a section with milestones.  See attached diff.  Comments are
welcome.  Please keep in mind that this is a rough sketch which might be
imperfect, because I didn't really think too long about it, and just
wrote it down.

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

[-- Attachment #2: changes.diff --]
[-- Type: text/plain, Size: 6434 bytes --]

--- targets.xml
+++ targets.xml
@@ -19,7 +19,7 @@
   <license/>
 
   <version>1.0</version>
-  <date>2005-12-11</date>
+  <date>2005-12-15</date>
 
   <chapter>
     <title>Targets</title>
@@ -294,7 +294,9 @@
           implements the "Gentoo for Mac OS X" route.  This route has
           proven to be unsuitable for Mac OS X, as the OS itself becomes
           a too big limitation for Portage to sucessfully emerge many
-          packages.  Hence, another direction is necessary.
+          packages, if one is not willing to overwrite packages, as in
+          the progressive profile.  Since many people prefer not to
+          touch the OS provided files, another direction is necessary.
         </p>
 
         <p>
@@ -302,7 +304,9 @@
           made, and because it is a rather big difference from a regular
           Mac OS X system, it was chosen to change the direction towards
           "Gentoo Portage for Mac OS X", to enable Gentoo's Mac OS X
-          project to continue and innovate again.
+          project to continue and innovate again.  The prefixed location
+          will avoid collissions, hence allowing many more packages to
+          install.
         </p>
 
         <p>
@@ -316,15 +320,15 @@
         <p>
           The Gentoo for Mac OS X installer that floats around the net
           currently is old and contains many bugs.  It has been removed
-          from the official project pages, because use of it is no
+          from the official project pages, because the use of it is no
           longer being supported.  We hope to release an updated
           installer to fill in this gap.
         </p>
       </body>
     </section><!-- }}} -->
 
-    <section><!-- {{{ Progress -->
-      <title>Progress</title>
+    <section><!-- {{{ Current Status -->
+      <title>Current Status</title>
       <body>
         <p>
           Because "Gentoo Portage for Mac OS X" requires Portage to be
@@ -350,12 +354,87 @@
           ebuild modifications that are not backwards compatible,
           applications are currently ported in an overlay.  This overlay
           currently contains applications like perl, python, apple-gcc,
-          vim, sed, awk, find, etc.  A full base install is covered
-          based on ebuild in the Gentoo Portage tree.
+          vim, sed, awk, find, etc.  A full base install is covered,
+          based on ebuilds in the Gentoo Portage tree.
         </p>
       </body>
     </section><!-- }}} -->
 
+    <section><!-- {{{ Milestones -->
+      <title>Milestones</title>
+      <body>
+        <p>
+          A few key points on the road towards implementation of Gentoo
+          Portage for Mac OS X can be indentified.  These milestones are
+          as follows:
+        </p>
+
+        <ol>
+          <li>
+            <b>Portage Prefix Support</b> - partial done<br />
+            In order to start doing anything, Portage has to be changed
+            to support prefixed installs.  This is a large and
+            non-trivial change that takes both time and lots of testing.
+          </li>
+          <li>
+            <b>Prefix-aware Portage Tree</b> - limited core done<br />
+            A Portage with prefix support, needs prefix-aware ebuilds,
+            just like a diesel engine doesn't run with gasoline.
+            Because the aims are for minimal changes to the Gentoo tree,
+            it should be a trivial task to convert ebuilds from the live
+            tree into something suitable for Portage with prefix
+            support.  Many more complicated packages, however, need
+            special treatments in order to recognise the prefix they
+            should install in correctly.  Ebuilds that have been
+            ported are put in the prefix overlay.  This overlay should
+            at minimal contain 20-30% of the live tree in order to be
+            considered as representative sample.
+          </li>
+          <li>
+            <b>Utilise Prefix-aware Portage</b><br />
+            Although the previous milestones implicitly require the
+            product to be used, this milestone is here to explicitly
+            require the prefix-aware portage to be used.  This does not
+            solely mean for OS X systems only, but also for Linux
+            systems or any other party that would like to join in this
+            development.  It is very important to have a few use cases,
+            in order to underline the fact that a prefix-aware portage
+            isn't just an OS X thing.  This milestone forms funding for
+            the next.
+          <li>
+            <b>Make Prefix Aware Portage Mainline Product</b><br />
+            This step will require a lot of efforts in the form of a
+            Gentoo Linux Enhancement Proposal (GLEP), but is a very
+            critical step in the whole path to get the changes made
+            accepted by the Gentoo community as a whole.  The changes
+            required for prefix-aware portage are everything but
+            trivial, and hence need approval by the community at large.
+            At this stage it helps to have several use cases, a fair
+            share of the Gentoo Portage tree converted and some really
+            strong armour.  This step won't be easy, and will require a
+            lot of efforts in writing the GLEP.  However, only if the
+            GLEP will be accepted, we can move on to the next milestone.
+            In case of a reject, we are outlaws.
+          </li>
+          <li>
+            <b>Make Gentoo Portage Tree Prefix-aware</b><br />
+            A logical conclusion of the accepted GLEP is to get the full
+            tree ported to the prefix-aware format.  Since the GLEP is
+            accepted, this might be done with some help from others to
+            speed up the process.  Again this task is non-trivial, since
+            updates occur all the time on the live tree, and they need
+            to be reflected in the new tree somehow.
+          </li>
+          <li>
+            <b>Roll Out Prefix-aware Portage</b><br />
+            This is not our job, but it is the end of this road.  In
+            order to be able to use the features of the tree, a capable
+            Portage has to be made the mainline product.
+          </li>
+        </ol>
+      </body>
+    </section><!-- }}} -->
+
   </chapter>
 
 </guide>

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

Hi,
I am still playing around with my idea on a chroot / unionfs based Gentoo
MacOSX which should not need prefixes.

How stores Gentoo its installed packages? Can I keep in sync two lists in
a overlay based approach, or do I have to do manual synchronization?

The problem is that in an overlay based system a file in the second folder
overshadows a file in the first folder. So if Gentoo keeps a file based
database of packages, I either have to synchronize myelf, or I could keep
a "clean" MacOSX file system, and overlay a pure "Gentoo" system.
If Gentoo uses a folder based approach, I think a mixed file system would
be possible.

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

Hi,

does there exist documentation about what is needed for a basic Gentoo
system is needed. I think my idea is to start from scratch, i.e. a basic
chroot jail, and after that start merging/mounting the needed folders.
This should start with the basic Unix file system hierarchy (i.e. /etc,
/usr and stuff).
After that the ffiles / folders neeeded for a Gentoo OSX system could be
added.

If no documentation exist, does there exist _simple_ bootstrap scripts
which I could use as starting points?

Regards
Dirk

-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Grobian]

On 16-12-2005 16:17:07 +0100, Dirk Schönberger wrote:
> Hi,
> 
> does there exist documentation about what is needed for a basic Gentoo
> system is needed. I think my idea is to start from scratch, i.e. a basic
> chroot jail, and after that start merging/mounting the needed folders.
> This should start with the basic Unix file system hierarchy (i.e. /etc,
> /usr and stuff).
> After that the ffiles / folders neeeded for a Gentoo OSX system could be
> added.
> 
> If no documentation exist, does there exist _simple_ bootstrap scripts
> which I could use as starting points?

I think you mean emerge -epv system on a Gentoo Linux system.  Otherwise
I go for a stage 1.  Have a search for catalyst, it's the installer
builder tool.


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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

>> If no documentation exist, does there exist _simple_ bootstrap scripts
>> which I could use as starting points?
>
> I think you mean emerge -epv system on a Gentoo Linux system.  Otherwise
> I go for a stage 1.  Have a search for catalyst, it's the installer
> builder tool.
>

The problem is that your average installer or stage 1 assumes that I want
a clean install, so he does most of its work doing copying and creating
stuff.
I have already a working Gentoo OSX system, so I don't need new stuff.
Just mounting the already existing stuff to he correct places.

I don't think a simple s/mkdir/mount/g would do the job on a stage 1
installer...

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

Re: [gentoo-osx] New document: Project targets

[Grobian]

Then I didn't understand your question.

On 16-12-2005 16:30:31 +0100, Dirk Schnberger wrote:
> I have already a working Gentoo OSX system, so I don't need new stuff.
> Just mounting the already existing stuff to he correct places.
> 
> I don't think a simple s/mkdir/mount/g would do the job on a stage 1
> installer...

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

Hi,

again some results from the unionfs theory.
Seems the real problem is not the unionfs, which seems to work, but instead
the problem to actually mount an existing file system as read-only.
For Mac OSX seems to work only the was to eiter direct mount from CD, or to
mount a disk image (.dmg).

The missing link seems to be a "Null file system" (nullfs), which allows to
mount a folder into another folder. Nullfs seem to exist on other systems,
like FreeBSD, but not on Darwin (or at least it is not build and deployed).

There seem to be some ideas in regards to being able to use a nullfs as a
Darwin kernel extension (.kext), but these ideas don't seem to be finished /
buggy.

Sorry, doesn't seem to work that way.
Regards
Dirk


-- 
gentoo-osx@gentoo.org mailing list

Re: [gentoo-osx] New document: Project targets

[Grobian]

How does the absense of a read-only file-system affect the ability to
have a union-mount only 'visible' for a specific user or user-process?
Or is this read-only thing necessary to solve another problem?
Essential for the union-mount solution to work, is that it can at
least be *only* visible/available for a given (user) process.  Otherwise
your system is less different from a progressive system.  Still in that
case, the union-mount solution might have some advantages, like simple
repair, and a backup procedure (unmount the union-mount, or restart the
machine -- assuming you didn't add the union-mount to fstab).

On 16-12-2005 22:02:40 +0100, Dirk Schnberger wrote:
> Hi,
> 
> again some results from the unionfs theory.
> Seems the real problem is not the unionfs, which seems to work, but instead
> the problem to actually mount an existing file system as read-only.
> For Mac OSX seems to work only the was to eiter direct mount from CD, or to
> mount a disk image (.dmg).
> 
> The missing link seems to be a "Null file system" (nullfs), which allows to
> mount a folder into another folder. Nullfs seem to exist on other systems,
> like FreeBSD, but not on Darwin (or at least it is not build and deployed).
> 
> There seem to be some ideas in regards to being able to use a nullfs as a
> Darwin kernel extension (.kext), but these ideas don't seem to be finished /
> buggy.
> 
> Sorry, doesn't seem to work that way.
> Regards
> Dirk
>

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

Re: [gentoo-osx] New document: Project targets

[Dirk Schönberger]

> How does the absense of a read-only file-system affect the ability to
> have a union-mount only 'visible' for a specific user or user-process?
> Or is this read-only thing necessary to solve another problem?
> Essential for the union-mount solution to work, is that it can at
> least be *only* visible/available for a given (user) process.  Otherwise
> your system is less different from a progressive system.  Still in that
> case, the union-mount solution might have some advantages, like simple
> repair, and a backup procedure (unmount the union-mount, or restart the
> machine -- assuming you didn't add the union-mount to fstab).

The idea seems to be that you have a "live" version of the host system (real
"/", which is mounted read-only and unioned with
a copy on write system).
Current Darwin only allows .dmg or mounting from an unmounted device. In
both cases the underlying system is
intrinsically read-only, i.e. the union fs is not really needed.
I don't think it is a good idea to unomount / remount read-only your root
file system.
If you clone a existing installation and mount this, I think you have
effectively a progressive system. This approach is mentioned in the
entoo-macos bootstrap howto.

That the union file system is visible to all processes becomes a secondary
problem (I think it just means that you could have only one parallel
Gentoo union / chroot)

The basic problem with the Darwin unionfs implementation is that you have to
have a (read-only) file system in the first place, which you can union to.
As far as I understand the Linux version (which may be only a wishlist entry
resp. a specification, you can do things like

mount folder1 read-only U folder2 read-only U folder 3 read-write (where U
is a concatenation operator)
The FreeBSD soltuins divides these usecases into the actual union (unionfs),
and the mount from a subfolder of a mounted deice (nullfs)



Regards
Dirk



-- 
gentoo-osx@gentoo.org mailing list