[gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.

[Grobian]

Replying to the gentoo-osx mailing list here to include the people 
actually being called.  For the sake of those people that haven't read 
this yet, I retain the lengthy quotes.

Kito wrote:
>
> On Aug 27, 2005, at 4:32 PM, Grobian wrote:
>
>> Kito wrote:
>>> First, I'll apologize for this being a brief brain-splurt...
>>>
>>>     As the new portage grows near(savior) with support for multiple
>>> PORTDIR, added to the increasing confusion/kludginess of the current
>>> collision-protect mess, why do we not start a repo for the
>>> base-system package ebuilds(bash,perl,python,readline,etc.) that
>>> gives a proper gentoo environment in an alt-prefix?
>>
>> I can't really think of a counter argument...
>>
>>> In the interim it can simply be an overlay, using a portage snapshot,
>>> giving us free reign to do what is needed to get the important things
>>> working without having to worry about Apple provided files. Then with
>>> some simple PATH mangling(think finks /sw/init) we can start making
>>> use of it now and actually be a step ahead of the game.
>>
>> I'm lovin' this idea.  kito++;  Completely fits into my idea of a
>> 'pilot'.
>>
>>>  Doing this outside the main tree has IMHO worked quite well for
>>> g/fbsd project, and allowed them to get their base-system in order
>>> before they had to go mucking up the tree with hacks that may or may
>>> not be permanent, and is also the reason they aren't hated quite as
>>> much as us by the other projects...
>>
>> We can't revert that.  Diego is getting some things done for us, we
>> would need too.  So we can simply fly on his wings every now and then.
>> Good.  Getting life when we actually have something?  Is it possible
>> to be against that?
>>
>> So, from a managing point of view, I throw in a few things here:
>> - who is in charge/takes the lead in setting something up
>> - what are the concrete steps to take
>
> First off, creating the repo. Path of least resistance would be adding
> an overlay in gentoo-src/gentoo-projects/darwin/macos, but thats not
> really the best way IMHO... Slickest way to stay as in sync as possible
> with the main tree would need to be investigated & established...maybe
> svn would be a candidate, not sure on that yet.

At best rely on existing architecture, with known tools.  I'm still 
frustrated that I haven't been able to install svn normally.  Where does 
Diego have his preliminary BSD stuff?

> Do the initial import of the minimum required packages from the main
> tree, which shouldn't be too hard, basically a stage1 (see a
> packages.build file in one of the linux profiles for instance) give or
> take some things.
>
> Create a new profile(s), which should probably be a complete tear down,
> Finn Thain has had some great suggestions in this area. FINN! Care to
> jump in here?

^^^ Finn ^^^ :D

> The user interface would need to be hashed out as well of course. How do
> you install/bootstrap it? Where is the local configuration data stored?
> This is an area that I think would be acceptable to take some Mac OS
> specific indulgences, such as plists for the main config data(prefix
> info, search paths, etc), pkgs/dmgs to bootstrap/install, and I also
> think we should abuse the umbrella Framework mechanism when feasible.

Wow, using plists would be a first start on getting portage widely 
accepted because it includes the buzz word XML.  LOL.  On a serious 
note, I think Apple has shown XML can work somehow.  At least it has an 
open character, and it's great when you can 'script' your Keynote 
presentation by just doing string manipulation in a big XML file.
So I would say, let's try to use this horrible XML on a pilot base for 
small configuration files.  Maybe we should do it better than Apple at 
some point because their XML does not always make use of the tree 
structure of XML.  For XML I would say: only deal with it if it looks 
appropriate for the case and it is relatively easy to extract the data 
(which is often very flat, as in the .plist files).
Let's indeed make it a 'native' application for OSX users.  Native in 
the sense of how it installs and looks like.
I may give file locations a thought today, but maybe I should know the 
Framework stuff a bit better first.  Can we install the whole Gentoo 
stuff in a Framework? or is it better to just use a shortest path 
algorithm and end with /gentoo?  Actually the user should be able to 
select a disk to install to during install...

>> - who will participate into this pilot system
>
> You can obviously count me in =)
I'd like to be part of this pilot too!

> Since we will be wanting to abuse the new hotness in portage as it
> becomes available, the portage team will have to be involved at least a
> little, probably whether they like it or not :p But this should bear
> some fruit that would further portage as well IMHO, not just Mac OS.

ferringb was in our channel two days ago with a small question I could 
help him out with on rsync.  If I got it well he was related with the 
OSX project from the start to get portage going.  Maybe he's the one to 
be in it this time too?

> Some random broad philosophy/design goals that I think should be stated...:
>
>   The repo should never ever never ever EVER rely on anything it doesn't
> know how to supply itself with, whether that be a tool, a library,
> knowledge of a filesystem, a host, a protocol, whatever. It doesn't
> matter how it gets it, it just needs to know at least one way to get it.
> This implies of course proper implementation of ferringbs BDEPENDS idea.

so, you mean if there is something (a filesystem) portage hasn't 
installed, then we should create the proper handles to deal with the OS 
provided one?  As in create a compatibility tool for "fdisk.HFS+".  I'm 
a bit clueless on how exactly you want to achieve what you want.  Maybe 
I don't understand correctly what you want exactly too.

>   Although we want this for ppc-macos at the moment, it should not be
> specific to either of those things, ppc, or macos. Adhering to this rule
> assumes a lot...again the BDEPENDS issue, and keeping as close to the
> main tree as possible, with those things in place, and done
> properly(i.e. what it REALLY takes to bootstrap an
> {x86,amd_64,ppc,ppc64,mips,sh,whatever}-{linux,*bsd,darwin,macos,whatever}
> toolchain) , you have a sane cross-compile ready repo, that is pretty
> damn portable.

That would be really great.

>   Binary packages have to work. Thats a fun one. But all this done
> properly, should allow for at least a little more consistency than the
> current situation. I'm still sold on using xar[1] for this despite the
> rather heavy deps (they are deps I would want in most any environment
> anyway - libcurl,ssl,libxml,zlib), and it just fits the bill too well
> imho, support for most standard arch specific data such bsd flags, ACLs,
> resource forks
> ,.etc as well an excellent TOC structure that is perfect for storing
> environment settings and package metadata.

Again XML.  If you do it XML, you have to do it all XML, something Apple 
apparently understood.  It appears we will have the blessings if we use 
XML, so I think we should.  In the end we can always dump all that XML 
into MonetDB/XQuery to have extremely fast querying over all the files, 
tree based.  I think it would seriously be the first project to use 
XQuery and XML for it's configuration.  However, if you come to think of 
it, it is a tree, an extensible tree, and might be a much more a logical 
choice than it appears to be.

>   Avoid package.provided or anything of its likeness like the plague.
> This repo needs to describe a toolchain from the ground up, regardless
> of the host. "What CAN it build and how?", not "What WON'T the host OS
> let me do".

Uhm, yes please!

>   Keep the number of ebuilds to a bare minimum. We can't get too carried
> away with maintaining a complete tree, or we risk drifting too far
> downstream and the zealots pushing Darwin/Mac OS support out of the main
> tree entirely. That would be bad. This can't go in the direction of a
> fork, just an experimental branch that will be merged back in at some
> point.

Ok, this requires identification of the main packages we need.  I think 
along the lines of Python, Perl, bash and such.  We should come up with 
a (preliminary|complete)? list.

>> - glasjnost and perestroika please!
>>
>> I think it's important to have a fairly focussed pilot shared by just
>> a very few devs to figure out how to get it set up and deal with it.
>
> I agree, the less noise, the more work will get done. Politics entering
> even a little will kill any hope of progress and momentum.

It appears we're on the same wave length here ;)

>
> --Kito
>
> [1] http://www.opendarwin.org/projects/xar/

-- 
Fabian Groffen
Gentoo for Mac OS X
-- 
gentoo-osx@g.o mailing list