Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Zac Medico <zmedico@g.o> posted 48B440F6.7020705@g.o,
> 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-----