On Mon, 29 Aug 2005, Brian Harring wrote:
> 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? Not sure I understand the problem... in glep 37, a virtual is replaced with a meta-package having a list of depends alternatives. If you add the vendor package to that list, and then make the vendor packages "package.preferred" where portage is a secondary package manager, surely there is no question that package xyz is the one you're after? (I'm assuming all repos share the same namespace WRT package names... if cpv's do not have to be unique accross repos, other solutions might be possible...) > 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 I don't understand why portage would go looking for deps in the filesystem. If configure can't find them, does it help that portage can? The last I read about this was here... http://article.gmane.org/gmane.linux.gentoo.devel/28154 I guess there is more too it? > but it doesn't cover the abi angle. I hadn't considered the ABI problem. In the short term I think a synthetic package.provided is okay, since most multilib machines cater to the ABI-ignorant. But, generating package.provided with a wrapper is a hack, so long term, a vendor package manager (or a shim on top of it) would have to state what ABI was used for each package, when queried. Knowing the ABIs of the vendor packages, and knowing the native ABI of the target domain (?), the resolver could probably do the right thing... > 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. :) I think these are the bugs which have been the gentoo-osx team's burden already... brave souls that they are :-) > 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? I probably need a better handle on the constraints of the relations between domains, repos, prefixes... anyway, here is my naive partial config. This config is premature, of course, but it might help me understand what is and is not possible in the rewrite if you would kindly shoot some holes in it ;-) Notes: I've used a hypothetical feature for collecting information about vendor packages -- presumably the apple domain also needs an ephemeral vdb to hold it (like package.provided). I don't know if this vendor domain needs a repo. I guess the main repo would have to mask broken/testing vendor deps as it sees fit, including those from other domains... -f [vdb] type = repo class = portage.installed_pkg.repository path = [rsync repo] type = repo class = portage.ebuild.repository path = /opt/gentoo/usr/portage [ppc-macos] type = config ACCEPT_KEYWORDS = "ppc-macos" [default domain] type = domain root = "/opt/gentoo" repositories = 'rsync repo' vdb config = ppc-macos [vendor-apple] type = config FEATURES = "query-apple-packages" ACCEPT_KEYWORDS = "ppc-darwin" [apple domain] type = domain root = "/" config = vendor-apple -- [email protected] mailing list
