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