1 |
> On Aug 29, 2005, at 5:30 AM, Finn Thain wrote: |
2 |
> |
3 |
> >I reckon XML is important, though perhaps not in the way you describe. |
4 |
> >As I see it, where ever portage is deployed as a secondary package |
5 |
> >manager, it needs to consult the primary one. That means that there |
6 |
> >needs to be a standard protocol for one package manager to query |
7 |
> >another. |
8 |
|
9 |
(I should have mentioned, you don't really need XML for this, you can |
10 |
generate /etc/package.provided by a wrapper around emerge. Then you can |
11 |
mask untested stuff in it using a single ppc-macos profile and avoid the |
12 |
bogus package.provided files in all the present macos profiles.) |
13 |
|
14 |
> I'm not sure I agree. I think this gets too close to a package.provided |
15 |
> situation, portage will never know enough about another systems packages |
16 |
> to map their functionality to its own. I think its preferable to let |
17 |
> portage handle what it knows first hand before trying to force it data |
18 |
> from a foreign host. |
19 |
|
20 |
I'm not proposing that one "injects" non-identical packages under the same |
21 |
names. Actually, I have been against that since the beginning. |
22 |
|
23 |
I was thinking of something like, at run time, query the vendor package |
24 |
manager and use the result to populate the tree with packages like |
25 |
vendor-apple/sys-devel/xcode-1.5, vendor-sun/app-arch/cpio-x.y.z for |
26 |
example (please substitute sgi, bsd-ports, redhat or debian etc if you are |
27 |
hostile to any of my examples). |
28 |
|
29 |
Apple's XCode is closed source, and sun's cpio is now open. The former |
30 |
requires an ebuild to invoke installer(8), the latter requires an ebuild |
31 |
to build it from source. No-one is lying to portage here. |
32 |
|
33 |
And, if sys-apps/bsd-awk-x.y.z builds the same thing that apple ships, it |
34 |
can provide vendor-apple/sys-apps/bsd-awk. |
35 |
|
36 |
Also, the ebuilds for both vendor-apple/sys-apps/bsd-awk and |
37 |
sys-apps/bsd-awk should provide virtual/awk. So, when arbitrary ebuild foo |
38 |
wants generic awk (doesn't care about gnu extensions), it can depend on |
39 |
that virtual (unless virtuals are to be deprecated, in which case foo |
40 |
somehow has to depend on any vendor, including gentoo). |
41 |
|
42 |
> >IMHO, this sounds like a "gentoo-darwin" sub-project to gentoo-alt, |
43 |
> >along-side os x and bsd. It isn't really a fork except in as much as |
44 |
> >the profile arrangement doesn't really accomodate work on darwin proper |
45 |
> >(but then the profile arrangemnet is flawed anyway: it only exists this |
46 |
> >way because of the package.provided crutch). |
47 |
> |
48 |
> I was looking at it more as a place to develop some new portage |
49 |
> features...Gentoo/Darwin has always been lurking, this is more in the |
50 |
> area of just getting offsets working. |
51 |
|
52 |
OK, I see what you are getting at now. That was something that I failed to |
53 |
infer from the email you forwarded to the list. Most of what I said in |
54 |
reply isn't very relevant to that. Excepting that, if you can leverage |
55 |
existing packages, prefixed installs are much more useful -- having a |
56 |
complete set of deps installed on a prefix is not much better than a |
57 |
stage3 chroot with your home directory bind mounted below it. |
58 |
|
59 |
-f |
60 |
-- |
61 |
gentoo-osx@g.o mailing list |