On 08/17/2011 12:16 AM, Michał Górny wrote: > 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?
Well, if we could have simply relied upon a single variable like DEFINED_PHASES, then that approach would have been preferable. But since it would require making fragile assumptions about DEFINED_PHASES and SRC_URI variables, I think PROPERTIES would be a much more practical approach. > If someone uses it > incorrectly, the results are undefined. I don't think it's a difficult concept to grasp, so I think it's unlikely to be used incorrectly. Even if it is used incorrectly, I don't see it causing major problems. > With older PMs, results are > undefined. The worst case is that some redundant packages are pulled into the dependency graph, which is the legacy behavior anyway, so there's no net loss. > 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. As Ulrich has already mentioned, virtual/ruby-* define phases, so your fragile assumptions are falling apart again. > And still I think implementing stuff like that is just an ugly hack > instead of fixing the real issue. Is the real issue that ebuild developers aren't using workarounds in order to overcome the shortcomings of some dependency resolvers? Really? -- Thanks, Zac
