[gentoo-dev] News item: app-emulation/wine split and slotting

[gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

[-- Attachment #1.1.1: Type: text/plain, Size: 2937 bytes --]

Plan is to move the packages into the repo as masked shortly after final
approval of the news item.  At that point, any testers would be greatly
appreciated.

The split is a little confusing for those new to the concept and there
have already been several internal revisions to help convey the purpose
of the multiple new packages.  If you don't think it is clear, please
let me know any suggestions you might have on the wording.



Title: app-emulation/wine split and slotting
Author: NP-Hardass <NP-Hardass@gentoo.org>
Content-Type: text/plain
Posted: 2017-03-27
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-emulation/wine:0

Starting with Wine 2.0, Wine in Gentoo is transitioning away from its
traditional packaging and toward a new, split and slotted, Wine.

As many Wine users know, there are often regressions or an application
works better on one version of wine than another.  Going forward,
packaging in Gentoo will allow simultaneous installation of multiple
versions of Wine.

Additionally, to expedite vanilla releases as well as permit multiple
configurations for each Wine installation, the major patchsets have
been split out into separate packages.

Going forward, app-emulation/wine will transition to:
app-emulation/wine-vanilla: upstream Wine with no external patchsets
             (like if the old packaging forced USE="-staging -d3d9")
app-emulation/wine-staging: Wine with Wine-Staging's patchset
             (like if the old packaging forced USE="+staging -d3d9")
app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset
             (like if the old packaging forced USE="-staging +d3d9")
app-emulation/wine-any: Wine with any of the patchsets or flags
             (exactly like the old packaging regarding USE flags)

wine-any exists to allow the user to build any combination that they'd
like (like the old packaging).  This means the user could use wine-any
to use both Wine-Staging and Gallium Nine.  Alternatively, the user
could use wine-any to try out another configuration from other
packages.  For example, the user could build wine-vanilla without
PulseAudio, and could build wine-any with PulseAudio.  The sky is the
limit on how a user may choose to use app-emulation/wine-any.

Users may opt for any specific package, or may emerge virtual/wine,
which is provided for dependency resolution.
Maintainers: Please note, app-emulation/wine will be dropped, so
please use virtual/wine going forward.

Users may call each version specifically, or may call a symlink based
on their installed patchset, for example wine-2.1, wine-staging-2.2,
or wine-d3d9.

Symlinks for wine are managed with app-eselect/eselect-wine.
# eselect wine set wine-vanilla-2.0
/usr/bin/wine -> /usr/bin/wine-vanilla-2.0
# eselect wine set --staging wine-staging-2.4
/usr/bin/wine-staging -> /usr/bin/wine-staging-2.4



-- 
NP-Hardass

[-- Attachment #1.1.2: 2017-03-27-split-and-slotted-wine.en.txt --]
[-- Type: text/plain, Size: 2418 bytes --]

Title: app-emulation/wine split and slotting
Author: NP-Hardass <NP-Hardass@gentoo.org>
Content-Type: text/plain
Posted: 2017-03-27
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-emulation/wine:0

Starting with Wine 2.0, Wine in Gentoo is transitioning away from its
traditional packaging and toward a new, split and slotted, Wine.

As many Wine users know, there are often regressions or an application
works better on one version of wine than another.  Going forward, 
packaging in Gentoo will allow simultaneous installation of multiple
versions of Wine.

Additionally, to expedite vanilla releases as well as permit multiple
configurations for each Wine installation, the major patchsets have
been split out into separate packages.

Going forward, app-emulation/wine will transition to:
app-emulation/wine-vanilla: upstream Wine with no external patchsets
             (like if the old packaging forced USE="-staging -d3d9")
app-emulation/wine-staging: Wine with Wine-Staging's patchset
             (like if the old packaging forced USE="+staging -d3d9")
app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset
             (like if the old packaging forced USE="-staging +d3d9")
app-emulation/wine-any: Wine with any of the patchsets or flags
             (exactly like the old packaging regarding USE flags)

wine-any exists to allow the user to build any combination that they'd
like (like the old packaging).  This means the user could use wine-any
to use both Wine-Staging and Gallium Nine.  Alternatively, the user
could use wine-any to try out another configuration from other
packages.  For example, the user could build wine-vanilla without
PulseAudio, and could build wine-any with PulseAudio.  The sky is the
limit on how a user may choose to use app-emulation/wine-any.

Users may opt for any specific package, or may emerge virtual/wine,
which is provided for dependency resolution.
Maintainers: Please note, app-emulation/wine will be dropped, so
please use virtual/wine going forward.

Users may call each version specifically, or may call a symlink based
on their installed patchset, for example wine-2.1, wine-staging-2.2,
or wine-d3d9.

Symlinks for wine are managed with app-eselect/eselect-wine.
# eselect wine set wine-vanilla-2.0
/usr/bin/wine -> /usr/bin/wine-vanilla-2.0
# eselect wine set --staging wine-staging-2.4
/usr/bin/wine-staging -> /usr/bin/wine-staging-2.4

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 29 bytes --]

Posted

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3360 bytes --]

On czw, 2017-04-06 at 21:18 -0400, NP-Hardass wrote:
> Plan is to move the packages into the repo as masked shortly after final
> approval of the news item.  At that point, any testers would be greatly
> appreciated.
> 
> The split is a little confusing for those new to the concept and there
> have already been several internal revisions to help convey the purpose
> of the multiple new packages.  If you don't think it is clear, please
> let me know any suggestions you might have on the wording.
> 
> 
> 
> Title: app-emulation/wine split and slotting
> Author: NP-Hardass <NP-Hardass@gentoo.org>
> Content-Type: text/plain
> Posted: 2017-03-27
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: app-emulation/wine:0
> 
> Starting with Wine 2.0, Wine in Gentoo is transitioning away from its
> traditional packaging and toward a new, split and slotted, Wine.
> 
> As many Wine users know, there are often regressions or an application
> works better on one version of wine than another.  Going forward,
> packaging in Gentoo will allow simultaneous installation of multiple
> versions of Wine.
> 
> Additionally, to expedite vanilla releases as well as permit multiple
> configurations for each Wine installation, the major patchsets have
> been split out into separate packages.
> 
> Going forward, app-emulation/wine will transition to:
> app-emulation/wine-vanilla: upstream Wine with no external patchsets
>              (like if the old packaging forced USE="-staging -d3d9")
> app-emulation/wine-staging: Wine with Wine-Staging's patchset
>              (like if the old packaging forced USE="+staging -d3d9")
> app-emulation/wine-d3d9: Wine with Ixit's Gallium Nine patchset
>              (like if the old packaging forced USE="-staging +d3d9")
> app-emulation/wine-any: Wine with any of the patchsets or flags
>              (exactly like the old packaging regarding USE flags)
> 
> wine-any exists to allow the user to build any combination that they'd
> like (like the old packaging).  This means the user could use wine-any
> to use both Wine-Staging and Gallium Nine.  Alternatively, the user
> could use wine-any to try out another configuration from other
> packages.  For example, the user could build wine-vanilla without
> PulseAudio, and could build wine-any with PulseAudio.  The sky is the
> limit on how a user may choose to use app-emulation/wine-any.
> 
> Users may opt for any specific package, or may emerge virtual/wine,
> which is provided for dependency resolution.
> Maintainers: Please note, app-emulation/wine will be dropped, so
> please use virtual/wine going forward.
> 
> Users may call each version specifically, or may call a symlink based
> on their installed patchset, for example wine-2.1, wine-staging-2.2,
> or wine-d3d9.
> 
> Symlinks for wine are managed with app-eselect/eselect-wine.
> # eselect wine set wine-vanilla-2.0
> /usr/bin/wine -> /usr/bin/wine-vanilla-2.0
> # eselect wine set --staging wine-staging-2.4
> /usr/bin/wine-staging -> /usr/bin/wine-staging-2.4

So, the whole idea is that you can install vanilla and e.g. staging
side-by-side?

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?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 1216 bytes --]

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))

-- 
NP-Hardass


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[NP-Hardass]

[-- Attachment #1.1: Type: text/plain, Size: 5585 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] News item: app-emulation/wine split and slotting

[Vadim A. Misbakh-Soloviov]

> 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?

Why don't leave that "any" package just "wine" as it was before?..