Opened 7 years ago
Last modified 7 years ago
#54386 new defect
variants set with default_variant don't propagate the same way as variants set by the user do.
Reported by: | RJVB (René Bertin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | |
Keywords: | Cc: | neverpanic (Clemens Lang) | |
Port: |
Description
I'm not sure if this is a bug or a feature, or something I'm doing wrong (so fee free to change the ticket type).
Consider an audio-related port:foo
depending (directly or indirectly) on port:portaudio
in a future in which that port has moved Jack support to a +jack
variant (as I should have proposed by now). Foo does
variant jack description "Enable the use of Jack" { # whatever else we need to do for Jack support } # we enable Jack support by default, but don't need to make it a # hard requirement on all dependencies default_variants +jack
I for one would expect that the port will behave the same way when installing from scratch if one does
> port install foo
or
> port install foo +jack
because that's how I interpret the intended effect of the default_variants statement.
When you test as construct like this with port rdeps
it would appear that variants set by default_variants
don't propagate the same way, at least not for indirect dependencies on port:portaudio
. IOW, if portaudio is an indirect dependency of port:foo, I'm seeing (as expected)
> port rdeps foo +jack ... portaudio jack ...
All other things being equal I'd expect to see the same output when I do port rdeps foo
, but in reality the output from that command is the same as the output of port rdeps foo -jack
.
If this is intended, is there a way to set a variant programmatically so that it propagates? I already tried various approaches (including variant_set jack
but if that function does anything it's done in the wrong scope).
Change History (4)
comment:1 Changed 7 years ago by RJVB (René Bertin)
comment:2 Changed 7 years ago by mf2k (Frank Schima)
Summary: | variants set with defaut_variant don't propagate the same way variants set by the user does. → variants set with default_variant don't propagate the same way as variants set by the user do. |
---|
comment:3 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
It behaves as intended, as far as I know, and no, there's no support for what you want to have happen.
comment:4 Changed 7 years ago by RJVB (René Bertin)
I'd be curious to know why this is the intended behaviour, which feels like an inconsistency and probably requires additional processing.
(ouch, and if someone can remove the last 2 characters from the subject I'd be grateful :-/)