-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duncan wrote: > Zac Medico <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], > excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700: > >> Duncan wrote: >>> I therefore believe I like just moving them all to a *virtual*/ >>> category better, thus obviating the need for that particular property >>> in the first place. >> This has been suggested elsewhere in the thread [1] but I think the the >> PROPERTIES approach will be more flexible and practical for the reasons >> that I've already stated. >> >> [1] >> http://archives.gentoo.org/gentoo-dev/ > msg_65636255c9d284e51898e826cae09ffd.xml > > Maybe it's just 'cause I'm not a dev, but I don't see the reasons you > state there as a problem. I specifically addressed the java-virtuals > category by suggesting that the trigger could be on "virtual" in the > category, not on the single category "virtual", so java-virtuals would be > included as would any other *virtual* category, and the java folks > wouldn't have to move it after all. > > Moves as for kde/kde-meta might be an issue, but I don't believe any more > so than any other package move, and since they're "virtual", possibly > less so. The splits, as for qt, might be more confusing, but it's a > one-time split either now or (for future packages) whenever they go > virtual, at which point there's a lot of work going into them anyway. > >>From my perspective, that's not significant additional cost, at least > compared to the cost associated with the PROPERTIES=virtual in the first > place. Given the advantages, including the clarity of having the virtual > property out where all can see it in the category name itself, I think > it's worth the relatively small additional cost. > > That said, it'd be nice, and to me, worth the cost, particularly as > compared to the cost of implementing a new property anyway, but since I'm > not the one implementing it (in either the PM or the packages), feel free > to override that opinion. > > There's also conceivably some times when a virtual/pkg_name might not be > a proper fit regardless of the property, making the category proposal > somewhat less flexible. I can't think of anywhere that such might be the > case, but that doesn't mean there aren't such cases. But I still believe > the benefit of having the property out there for all to see more valuable > than any potentially lost flexibility. >
The PROPERTIES approach still seems a lot simpler and practical to me. It seems to me that the approach involving categories introduces needless complexity without bringing any really useful benefits. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0spcACgkQ/ejvha5XGaOTygCg0phbwIFENXHBKyKryAMkgQwo RJwAoOdcjRUJAmnPK/RTBV5S0REVaYhx =QzgD -----END PGP SIGNATURE-----
