On 04/10/2017 02:17 PM, Michał Górny wrote:
> 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.
Yes and no.  This goes back to the discussion a couple of weeks ago
(your thread actually "How to deal with package forks"[1]) about
separating out packages for large external patchsets.   This falls under
your category 2.  Previously it was 2B, and this change pushes it to 2A.
Snippet:
> 2. large patch sets / continuously rebased forks -- where the particular
> set of changes is usually applied to mainline or regularly rebased
> against mainline but without full separation (kernel patchsets, bitcoin
> patches);
[...]
> 
> The second group (patch sets) is more unclear. AFAICS some people argue
> that packages with major patch sets applied should be distinguished by
> separate package names. Others see that applying them via USE flags is
> easier.
> 
> Separate packages are used e.g. for different kernel patch sets. This
> has the following advantages:
> 
> 2a1. more clear distinction between base and patched version,
> 
> 2a2. cleaner when patch sets imply major changes, e.g. when some
> of the USE flags apply to patched version only,
> 
> 2a3. the packages can be bumped independently, without worrying that
> the patch set has not been updated yet.
> 
> A single package with USE flags is used e.g. for openssl (hpn patch
> set), bitcoincore (ljr patch set). This has the following advantages:
> 
> 2b1. available patches are cleanly exposed via USE flags,
> 
> 2b2. multiple patch sets can be combined in a single package,
> 
> 2b3. usually there is less work for the package maintainer.

In this case, Wine-Staging and Ixit's Gallium Nine both package
separately and often prefer to be packaged in distros separately.
Staging is a very large patchset, and Gallium Nine is a regularly
rebased but without full separation patchset.  Currently, Sarnex
generates our d3d9 patchset for us.  The package split isn't arbitrary,
it's only along large independent patchsets (effectively separate
upstreams).

> 
> 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.
> 
I can't speak for other users, but on the existing packaging, apart from
the patchset specific flags, I almost never touch the defaults on the
other flags.  Most of the flags that I know users care about are either
set by profile or are related to the one of the patchsets.
> 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? ;-)
> 
Internally, we had a discussion about this.  No, we aren't going to make
2^N packages.  Just one per large independent patchset, and one that the
user can use at their discretion if they are a power user (either as a
2B type package or as they so choose changing other sets of flags if
they want).  So if a new up and coming patchset appears, Foo,  new
package wine-foo and  wine-any (or whatever it is called) supports foo
as well.  "-any" itself is arbitrary.  Do you have a suggestion for a
better suffix?


As an aside, a major benefit to splitting here is that releases get made
significantly faster.  Lots of users complain about the speed that wine
releases get made.  There are often times where we are waiting on a
patchset to make a release (and then on another patchset to release
after that) and that can take weeks.  With the split, vanilla gets
updated immediately as there is nothing to wait on, then the patchsets
each come out and their ebuilds get updated as they come. (as you noted
in 2a3)

-- 
NP-Hardass

[1]
https://archives.gentoo.org/gentoo-dev/message/18d271b991a4088675444939ce1ee1a1