Gentoo Archives: gentoo-osx

From: Finn Thain <fthain@××××××××××××××××.au>
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: Tue, 30 Aug 2005 03:10:13
Message-Id: Pine.LNX.4.63.0508301201590.5950@loopy.telegraphics.com.au
In Reply to: Re: [gentoo-osx] Re: [RFC] Separate alt-prefix repo for base-system packages. by Kito
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

Replies