On 08/16/2011 01:29 AM, Michał Górny wrote: > On Tue, 16 Aug 2011 01:10:48 -0700 > Zac Medico <[email protected]> wrote: > >> On 08/16/2011 12:40 AM, Michał Górny wrote: >>> On Tue, 16 Aug 2011 00:26:41 -0700 >>> Zac Medico <[email protected]> wrote: >>>> On 08/16/2011 12:01 AM, Micha? Górny wrote: >>>>>>> Considering the number of different virtuals in this category, >>>>>>> maybe it would be a good idea to split it a little? What I'm >>>>>>> proposing is maybe creating some kind of '*-virtual' categories. >>>>>>> >>>>>>> For example, half of the current virtuals are prefixed with >>>>>>> 'perl-'. Maybe they could be transformed into 'perl-virtual/*'? >>>>>> >>>>>> If you're going to do that, then I'd suggest giving them some >>>>>> sort of tag that the package manager can rely upon in order to >>>>>> identify them as virtuals. For example, we could have the >>>>>> ebuilds set PROPERTIES=virtual [2], or we could simply specify >>>>>> (in PMS) that any category whose name matches the '*-virtual' >>>>>> pattern will contain virtuals. >>>>> >>>>> Doesn't DEFINED_PHASES==- serve that purpose nowadays? >>> >>>> Actually, since EAPI 4 we have default src_install, so it's >>>> possible to have ebuilds that have no defined phases but still >>>> install stuff. >>> >>> + empty SRC_URI? I guess something like the workdir fallback >>> conditions in PMS. >> >> When you consider that "live" ebuilds can have empty SRC_URI and >> download things during src_unpack, it seems more sensible and simple >> to introduce PROPERTIES="live" or something like it. That way, we'll >> have a simple boolean flag and won't have to make any fragile >> assumptions. > > Live ebuild have to redefine src_unpack() which makes DEFINED_PHASES!=-.
Sure, but the fact that you have to check two variables like that and make these fragile assumptions makes it seem like we're building a fragile kludge rather than something that's really practical. -- Thanks, Zac
