On Fri, 2005-12-30 at 21:49 +0900, Jason Stubbs wrote: > On Friday 30 December 2005 21:17, Spider (DmD Lj) wrote: > > > > No, what you suggested was that for the case of when you depend on a > > SLOT, then the tree is flattened. My point was for the generic case : > > > > DEPEND=">=kde-base/kdelibs-3.0" (as many ebuilds look today) > > > > is then expanded to the current matching SLOT of kdelibs, so even if > > there -wasn't- a SLOT requirement beforehand, there is one afterwards. > > Okay, I misinterpreted. Anyway, it looks like neither of our ideas will work: > > app-text/docbook-sgml/docbook-sgml-1.0.ebuild: > > RDEPEND="app-text/sgml-common app-text/openjade > >=app-text/docbook-dsssl-stylesheets-1.64 > >=app-text/docbook-sgml-utils-0.6.6 > ~app-text/docbook-sgml-dtd-3.0 > ~app-text/docbook-sgml-dtd-3.1 > ~app-text/docbook-sgml-dtd-4.0 > ~app-text/docbook-sgml-dtd-4.1"
> docbook-sgml-dtd-3.0-r3.ebuild:SLOT="3.0" > docbook-sgml-dtd-3.1-r3.ebuild:SLOT="3.1" > docbook-sgml-dtd-4.0-r3.ebuild:SLOT="4.0" > docbook-sgml-dtd-4.1-r3.ebuild:SLOT="4.1" > Hmm, however theese are the ~ atoms, I'm not quite sure how those are treated in the current tree, however in "my" proposal it would block against "requirement of same package with different SLOT. However, since the ~ atoms are explicit and separate ( this depend tree could as well be called : app-text/docbook-sgml-dtd:3.0 app-text/docbook-sgml-dtd:3.1 app-text/docbook-sgml-dtd:4.0 app-text/docbook-sgml-dtd:4.1 Which, for some reason, should be supported : ) Either by casing out appearances where multiple SLOTs are depended on by -one- package, or by saying that ~ is special-cased due to its stricter limitations, which would make it pass by the SLOT check. ( no, its not an elegant solution, but it might work ;) //Spider -- begin .signature Tortured users / Laughing in pain See Microsoft KB Article Q265230 for more information. end
signature.asc
Description: This is a digitally signed message part
