1 |
On 04/10/2017 02:17 PM, Michał Górny wrote: |
2 |
> On pon, 2017-04-10 at 13:52 -0400, NP-Hardass wrote: |
3 |
>> On 04/10/2017 01:31 PM, Michał Górny wrote: |
4 |
>>> So, the whole idea is that you can install vanilla and e.g. staging |
5 |
>>> side-by-side? |
6 |
>> |
7 |
>> That's 50% of it. The other 50% is that since Windows applications |
8 |
>> often are better supported in one version or another, you can also have |
9 |
>> multiple versions installed side by side (=wine-vanilla-2.1 and |
10 |
>> =wine-vanilla-2.2 for example) |
11 |
>>> |
12 |
>>> Is 'any' always called 'any'? Does it mean that I can have installed |
13 |
>>> e.g. 'any[staging]' and 'staging', and both would be the same thing? |
14 |
>>> |
15 |
>> |
16 |
>> Right. We were sort of at a loss for the best way to signify to the |
17 |
>> user that any is for them to do whatever they want with (even if it is |
18 |
>> redundant). Giving it the -any suffix was our best idea XD That said, |
19 |
>> the virtual places -any in priority last, so the usually more or less |
20 |
>> has to consciously decide to use it (which would for the most part avoid |
21 |
>> accidental redundancy) The two primary uses of any *should* be using |
22 |
>> multiple patchsets simultaneously (any[d3d9,staging]) and using any to |
23 |
>> slightly alter flags from any of the others (example in the news item |
24 |
>> given as using one audio system in -vanilla (gstreamer) and another in |
25 |
>> -any (pulseaudio)) |
26 |
> |
27 |
> Honestly? I don't like that. I can see your point but I feel like it's |
28 |
> pretty much having app-emulation/wine1, /wine2, /wine3... whose only |
29 |
> purpose would be to allow having different USE flag sets. |
30 |
Yes and no. This goes back to the discussion a couple of weeks ago |
31 |
(your thread actually "How to deal with package forks"[1]) about |
32 |
separating out packages for large external patchsets. This falls under |
33 |
your category 2. Previously it was 2B, and this change pushes it to 2A. |
34 |
Snippet: |
35 |
> 2. large patch sets / continuously rebased forks -- where the particular |
36 |
> set of changes is usually applied to mainline or regularly rebased |
37 |
> against mainline but without full separation (kernel patchsets, bitcoin |
38 |
> patches); |
39 |
[...] |
40 |
> |
41 |
> The second group (patch sets) is more unclear. AFAICS some people argue |
42 |
> that packages with major patch sets applied should be distinguished by |
43 |
> separate package names. Others see that applying them via USE flags is |
44 |
> easier. |
45 |
> |
46 |
> Separate packages are used e.g. for different kernel patch sets. This |
47 |
> has the following advantages: |
48 |
> |
49 |
> 2a1. more clear distinction between base and patched version, |
50 |
> |
51 |
> 2a2. cleaner when patch sets imply major changes, e.g. when some |
52 |
> of the USE flags apply to patched version only, |
53 |
> |
54 |
> 2a3. the packages can be bumped independently, without worrying that |
55 |
> the patch set has not been updated yet. |
56 |
> |
57 |
> A single package with USE flags is used e.g. for openssl (hpn patch |
58 |
> set), bitcoincore (ljr patch set). This has the following advantages: |
59 |
> |
60 |
> 2b1. available patches are cleanly exposed via USE flags, |
61 |
> |
62 |
> 2b2. multiple patch sets can be combined in a single package, |
63 |
> |
64 |
> 2b3. usually there is less work for the package maintainer. |
65 |
|
66 |
In this case, Wine-Staging and Ixit's Gallium Nine both package |
67 |
separately and often prefer to be packaged in distros separately. |
68 |
Staging is a very large patchset, and Gallium Nine is a regularly |
69 |
rebased but without full separation patchset. Currently, Sarnex |
70 |
generates our d3d9 patchset for us. The package split isn't arbitrary, |
71 |
it's only along large independent patchsets (effectively separate |
72 |
upstreams). |
73 |
|
74 |
> |
75 |
> While of course there's really no reason to technically force all |
76 |
> variants to have the same USE flags, I'm against encouraging users to |
77 |
> fiddle with that more than necessary. That's an easy way to get them |
78 |
> confused a lot. Just imagine that the flags set for app-emu/wine now you |
79 |
> have to set for 4 packages consistently, and remember to update them or |
80 |
> switching between variants is going to result in an accidental different |
81 |
> build. |
82 |
> |
83 |
I can't speak for other users, but on the existing packaging, apart from |
84 |
the patchset specific flags, I almost never touch the defaults on the |
85 |
other flags. Most of the flags that I know users care about are either |
86 |
set by profile or are related to the one of the patchsets. |
87 |
> Plus, IMHO the '-any' name is just weird. What are you going to do when |
88 |
> you introduce a third patch set? Will you add four more ebuilds to cover |
89 |
> all the bases? ;-) |
90 |
> |
91 |
Internally, we had a discussion about this. No, we aren't going to make |
92 |
2^N packages. Just one per large independent patchset, and one that the |
93 |
user can use at their discretion if they are a power user (either as a |
94 |
2B type package or as they so choose changing other sets of flags if |
95 |
they want). So if a new up and coming patchset appears, Foo, new |
96 |
package wine-foo and wine-any (or whatever it is called) supports foo |
97 |
as well. "-any" itself is arbitrary. Do you have a suggestion for a |
98 |
better suffix? |
99 |
|
100 |
|
101 |
As an aside, a major benefit to splitting here is that releases get made |
102 |
significantly faster. Lots of users complain about the speed that wine |
103 |
releases get made. There are often times where we are waiting on a |
104 |
patchset to make a release (and then on another patchset to release |
105 |
after that) and that can take weeks. With the split, vanilla gets |
106 |
updated immediately as there is nothing to wait on, then the patchsets |
107 |
each come out and their ebuilds get updated as they come. (as you noted |
108 |
in 2a3) |
109 |
|
110 |
-- |
111 |
NP-Hardass |
112 |
|
113 |
[1] |
114 |
https://archives.gentoo.org/gentoo-dev/message/18d271b991a4088675444939ce1ee1a1 |