Re: [gentoo-dev] RFC: splitting virtual/

[Michał Górny]

On Tue, 16 Aug 2011 01:51:27 -0700
Zac Medico <zmedico@g.o> wrote:

> On 08/16/2011 01:29 AM, Michał Górny wrote:
> > On Tue, 16 Aug 2011 01:10:48 -0700
> > Zac Medico <zmedico@g.o> wrote:
> >
> >> On 08/16/2011 12:40 AM, Michał Górny wrote:
> >>> On Tue, 16 Aug 2011 00:26:41 -0700
> >>> Zac Medico <zmedico@g.o> 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