On pon, 2017-04-10 at 13:52 -0400, NP-Hardass wrote:
> On 04/10/2017 01:31 PM, Michał Górny wrote:
> > So, the whole idea is that you can install vanilla and e.g. staging
> > side-by-side?
> 
> That's 50% of it.  The other 50% is that since Windows applications
> often are better supported in one version or another, you can also have
> multiple versions installed side by side (=wine-vanilla-2.1 and
> =wine-vanilla-2.2 for example)
> > 
> > Is 'any' always called 'any'? Does it mean that I can have installed
> > e.g. 'any[staging]' and 'staging', and both would be the same thing?
> > 
> 
> Right.  We were sort of at a loss for the best way to signify to the
> user that any is for them to do whatever they want with (even if it is
> redundant).  Giving it the -any suffix was our best idea XD  That said,
> the virtual places -any in priority last, so the usually more or less
> has to consciously decide to use it (which would for the most part avoid
> accidental redundancy)  The two primary uses of any *should* be using
> multiple patchsets simultaneously (any[d3d9,staging])  and using any to
> slightly alter flags from any of the others (example in the news item
> given as using one audio system in -vanilla (gstreamer) and another in
> -any (pulseaudio))

Honestly? I don't like that. I can see your point but I feel like it's
pretty much having app-emulation/wine1, /wine2, /wine3... whose only
purpose would be to allow having different USE flag sets.

While of course there's really no reason to technically force all
variants to have the same USE flags, I'm against encouraging users to
fiddle with that more than necessary. That's an easy way to get them
confused a lot. Just imagine that the flags set for app-emu/wine now you
have to set for 4 packages consistently, and remember to update them or
switching between variants is going to result in an accidental different
build.

Plus, IMHO the '-any' name is just weird. What are you going to do when
you introduce a third patch set? Will you add four more ebuilds to cover
all the bases? ;-)

-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to