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

[Zac Medico]

On 08/17/2011 12:16 AM, Michał Górny wrote:
> 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?

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