Opened 6 years ago

Last modified 6 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)


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


> 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

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 6 years ago by RJVB (René Bertin)

(ouch, and if someone can remove the last 2 characters from the subject I'd be grateful :-/)

comment:2 Changed 6 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 6 years ago by ryandesign (Ryan 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 6 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.

Note: See TracTickets for help on using tickets.