On Friday 08 April 2005 00:05, Ciaran McCreesh wrote: > On Thu, 7 Apr 2005 23:53:38 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | > An example of exactly how portage would 'solve' this would be > | > helpful. Would it ask for an unmerge of gvim-6.3 or would it include > | > an upgrade of gvim-6.3 as part of the "emerge ~vim-7"? > | > | Yep something like that. The specifics of what to do in various cases > | such as that one have not been worked out but are irrelevant to the > | glep anyway. The glep only need require that it is handled. > > Better to say *how* it would be handled IMO.
Yes, it is. But not in this GLEP. > | > 3) We don't specify every virtual in every profile thanks to > | > cascades. > | > | And...? I guess you are referring to "profiles must provide a default > | ..." but that _is_ a correct statement. If somebody wants to create a > | new profile that doesn't derive from base, they must specify defaults > | for all the virtuals. > > Serves them right for not deriving from base :) In other words, irrelevant. > | > 4) Backwards compatibility -- all virtuals ebuilds should include > | > DEPEND=">=portage-2.whatever" as well as the "|| ( foo bar )" stuff. > | > | Why? The virtuals would be no different to regular packages. > > Oh, actually, it's worse than I thought. You can't use virtual/ as the > prefix *at all*. > > [EMAIL PROTECTED] overlay 0 0.10 $ cat virtual/breakme/breame-1.ebuild > [EMAIL PROTECTED] overlay 0 0.09 $ cat app-misc/breakme/breakme-1.ebuild > DEPEND="virtual/breakme" > KEYWORDS="x86" > [EMAIL PROTECTED] overlay 1 0.05 $ FEATURES=-candy emerge > app-misc/breakme -pv > > These are the packages that I would merge, in order: > > Calculating dependencies - > !!! Cannot resolve a virtual package name to an ebuild. > !!! This is a bug, please report it. (virtual/breakme-1) > > AFAIK, virtual can't be removed from categories either... Can fix this for portage-2.0.51.20. Regards, Jason Stubbs -- [email protected] mailing list
