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

[Brian Harring]

Sidenote, no need to cc, just joined the ml for the discussion in the 
meantime since people occasionally forget to cc (I know I do).

On Tue, Aug 30, 2005 at 01:09:49PM +1000, Finn Thain wrote:
> > 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).
The rewrite's domain's abstraction (additionally the goal of binding 
the resolver to the domain, and being able to do inter-domain 
resolving) would allow for this, but I *really* don't think it'll work 
well.

Reasoning is, how do you know that pkg xyz is actually the package 
you're after?  The expanded restrictions subsystem, specifically 
ability to depends based on contents restrictions (I want the pkg that 
owns file abc essentially) gives basic ability for this, but it 
doesn't cover the abi angle.

What you're proposing could sort of be hacked together to pull off 
strictly for src compiles, probably with a good collection of 
impossible to quash annoying bugs.  Doing it for binaries is a helluva 
lot harder though. :)

> > >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.

The rewrite's general core is intended to allow for alt 
formats/repos/whatever jammed into it; that said, making seperate 
formats play nice with each other (unless they can natively) isn't 
something I think is incredibly easy to pull off, as mentioned above.

Thoughts?
~harring