Re: [gentoo-dev] News item: app-emulation/wine split and slotting
> 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?..
Re: [gentoo-dev] News item: app-emulation/wine split and slotting
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
Re: [gentoo-dev] News item: app-emulation/wine split and slotting
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] News item: app-emulation/wine split and slotting
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] News item: app-emulation/wine split and slotting
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> 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] News item: app-emulation/wine split and slotting
Posted -- NP-Hardass signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item: app-emulation/wine split and slotting
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-HardassContent-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 Title: app-emulation/wine split and slotting Author: NP-Hardass 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