Gentoo Archives: gentoo-osx

From: Kito <kito@g.o>
To: gentoo-osx@l.g.o
Cc: Brian Harring <ferringb@g.o>
Subject: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages.
Date: Mon, 29 Aug 2005 16:48:36
Message-Id: 2134124F-DB37-4FFC-9F76-C75BC62B0A7F@gentoo.org
In Reply to: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. by Finn Thain
1 On Aug 29, 2005, at 5:30 AM, Finn Thain wrote:
2
3 >
4 >
5 > On Mon, 29 Aug 2005, Grobian wrote:
6 >
7 >> Kito wrote:
8 >>>
9 >>> On Aug 27, 2005, at 4:32 PM, Grobian wrote:
10 >
11 > At the moment, ppc-macos would need the collision-protect feature, but
12 > once we have a feature for prefixed installs, that should be used
13 > instead
14 > (by default, at least).
15 >
16 >>> The user interface would need to be hashed out as well of course.
17 >>> How
18 >>> do you install/bootstrap it?
19 >
20 > It would be nice to have ebuilds that could invoke the Darwin Build
21 > Scripts (and merge the result on a ROOT).
22
23 Yeap. already planned on using this to build a libSystem, etc.
24
25 >
26 > http://www.opendarwin.org/projects/darwinbuild/releases/
27 >
28 > Given such ebuilds, surely catalyst can bootstrap it.
29 >
30 >>> Where is the local configuration data stored? This is an area that I
31 >>> think would be acceptable to take some Mac OS specific indulgences,
32 >>> such as plists for the main config data(prefix info, search paths,
33 >>> etc), pkgs/dmgs to bootstrap/install, and I also think we should
34 >>> abuse
35 >>> the umbrella Framework mechanism when feasible.
36 >>
37 >> Wow, using plists would be a first start on getting portage widely
38 >> accepted because it includes the buzz word XML. LOL. On a serious
39 >> note, I think Apple has shown XML can work somehow. At least it
40 >> has an
41 >> open character, and it's great when you can 'script' your Keynote
42 >> presentation by just doing string manipulation in a big XML file.
43 >>
44 >> So I would say, let's try to use this horrible XML on a pilot base
45 >> for
46 >> small configuration files. Maybe we should do it better than
47 >> Apple at
48 >> some point because their XML does not always make use of the tree
49 >> structure of XML. For XML I would say: only deal with it if it looks
50 >> appropriate for the case and it is relatively easy to extract the
51 >> data
52 >> (which is often very flat, as in the .plist files).
53 >
54 > I reckon XML is important, though perhaps not in the way you
55 > describe. As
56 > I see it, where ever portage is deployed as a secondary package
57 > manager,
58 > it needs to consult the primary one. That means that there needs to
59 > be a
60 > standard protocol for one package manager to query another.
61 >
62
63 I'm not sure I agree. I think this gets too close to a
64 package.provided situation, portage will never know enough about
65 another systems packages to map their functionality to its own. I
66 think its preferable to let portage handle what it knows first hand
67 before trying to force it data from a foreign host.
68
69 >
70 >> Let's indeed make it a 'native' application for OSX users. Native in
71 >> the sense of how it installs and looks like. I may give file
72 >> locations a
73 >> thought today, but maybe I should know the Framework stuff a bit
74 >> better
75 >> first. Can we install the whole Gentoo stuff in a Framework? or
76 >> is it
77 >> better to just use a shortest path algorithm and end with /gentoo?
78 >> Actually the user should be able to select a disk to install to
79 >> during
80 >> install...
81 >
82 > I reckon get it working (with an "upstream darwin" profile) in a
83 > chroot
84 > stage first (which could double as a boot disk).
85 >
86
87 I want to start a lot smaller than that first. Think stage1. You
88 can't boot a stage1, its a just the corelibs and a toolchain pretty
89 much.
90
91
92
93 >>> The repo should never ever never ever EVER rely on anything it
94 >>> doesn't know how to supply itself with, whether that be a tool, a
95 >>> library, knowledge of a filesystem, a host, a protocol, whatever. It
96 >>> doesn't matter how it gets it, it just needs to know at least one
97 >>> way
98 >>> to get it. This implies of course proper implementation of ferringbs
99 >>> BDEPENDS idea.
100 >>
101 >> so, you mean if there is something (a filesystem) portage hasn't
102 >> installed, then we should create the proper handles to deal with
103 >> the OS
104 >> provided one? As in create a compatibility tool for "fdisk.HFS
105 >> +". I'm
106 >> a bit clueless on how exactly you want to achieve what you want.
107 >> Maybe
108 >> I don't understand correctly what you want exactly too.
109 >
110 > This is how I would handle that case:
111 >
112 > If a program (say fsck_hfs) is available upstream, build it with Dawin
113 > Build, merge it with portage (I expect an eclass for darwin build is
114 > required, and of course an ebuild for diskdev_cmds.)
115
116 About what I was thinking...
117
118 >>
119 >>> Binary packages have to work. Thats a fun one. But all this done
120 >>> properly, should allow for at least a little more consistency
121 >>> than the
122 >>> current situation. I'm still sold on using xar[1] for this
123 >>> despite the
124 >>> rather heavy deps (they are deps I would want in most any
125 >>> environment
126 >>> anyway - libcurl,ssl,libxml,zlib), and it just fits the bill too
127 >>> well
128 >>> imho, support for most standard arch specific data such bsd flags,
129 >>> ACLs, resource forks ,.etc as well an excellent TOC structure
130 >>> that is
131 >>> perfect for storing environment settings and package metadata.
132 >>
133 >> Again XML. If you do it XML, you have to do it all XML, something
134 >> Apple
135 >> apparently understood. It appears we will have the blessings if
136 >> we use
137 >> XML, so I think we should. In the end we can always dump all that
138 >> XML
139 >> into MonetDB/XQuery to have extremely fast querying over all the
140 >> files,
141 >> tree based. I think it would seriously be the first project to use
142 >> XQuery and XML for it's configuration. However, if you come to
143 >> think of
144 >> it, it is a tree, an extensible tree, and might be a much more a
145 >> logical
146 >> choice than it appears to be.
147 >
148 > Why not use one of the open source .pkg tools to generate binary
149 > packages?
150 > Kito tells me he has already been able to unpack .pkg format and
151 > install
152 > it via portage.
153
154 Thats just to get extract files...I'm talking about binary packages
155 that portage can use. I don't like the current tbz2 hack.
156
157 I have no interest personally in producing packages with a
158 proprietary format for portage. Be a nice feature for OS X users and
159 devs sure, but thats more like an add-on bells-and-whistles type
160 feature... patches accepted ;)
161
162 >
163 >>> Avoid package.provided or anything of its likeness like the
164 >>> plague.
165 >>> This repo needs to describe a toolchain from the ground up,
166 >>> regardless
167 >>> of the host. "What CAN it build and how?", not "What WON'T the
168 >>> host OS
169 >>> let me do".
170 >>
171 >> Uhm, yes please!
172 >
173 > Hear, hear!
174 >
175 >>> Keep the number of ebuilds to a bare minimum. We can't get too
176 >>> carried away with maintaining a complete tree, or we risk
177 >>> drifting too
178 >>> far downstream and the zealots pushing Darwin/Mac OS support out of
179 >>> the main tree entirely. That would be bad. This can't go in the
180 >>> direction of a fork, just an experimental branch that will be merged
181 >>> back in at some point.
182 >
183 > IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt,
184 > along-side os x and bsd. It isn't really a fork except in as much
185 > as the
186 > profile arrangement doesn't really accomodate work on darwin proper
187 > (but
188 > then the profile arrangemnet is flawed anyway: it only exists this way
189 > because of the package.provided crutch).
190
191 I was looking at it more as a place to develop some new portage
192 features...Gentoo/Darwin has always been lurking, this is more in the
193 area of just getting offsets working.
194
195 >
196 > -f
197 > --
198 > gentoo-osx@g.o mailing list
199 >
200
201 --
202 gentoo-osx@g.o mailing list

Replies

Subject Author
Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. Finn Thain <fthain@××××××××××××××××.au>