On Tue, 16 Aug 2011 01:51:27 -0700 Zac Medico <[email protected]> wrote:
> 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. And isn't a random PROPERTIES value more fragile? If someone uses it incorrectly, the results are undefined. With older PMs, results are undefined. While having empty SRC_URI and no DEFINED_PHASES guarantees that the ebuild won't install a file. That's just per-def, nothing can happen. And still I think implementing stuff like that is just an ugly hack instead of fixing the real issue. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
