"Nirbheek Chauhan" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Dec 2007 01:14:06 +0530:
> On Dec 10, 2007 8:44 PM, Robert Buchholz <[EMAIL PROTECTED]> wrote: >> That would still mean everything relies on n ebuilds with mutual >> blocks. Even if that would work and it block upgrades, it is still not >> a solution in terms of how to display a list of ebuilds in one tree in >> an ordered list. > > The mutual blocks can be via the very nature of the name of the ebuild > (ie, the scm_bbranch), and not via unmaintainable dep blocks in the > ebuilds. But what about when there's a dependency on any of several branches? That gets hard to maintain if there are multiple ebuilds with similar dependencies. However, that's where virtuals come in. Create a single virtual, depend on it, and you have a single dependency instead of a whole complex list to maintain in all the various depending ebuilds. Another alternative of course is an eclass, inherited by whatever otherwise depending ebuilds, that manages all the dependencies and blockages all in one spot. Which just means there are existing solutions for that angle, so it's out of scope for this GLEP. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
