From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 671A6139694 for ; Mon, 10 Apr 2017 19:04:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5BEE7E0DBD; Mon, 10 Apr 2017 19:04:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EFC7DE0D33 for ; Mon, 10 Apr 2017 19:04:48 +0000 (UTC) Received: from [192.168.10.30] (ool-4571a227.dyn.optonline.net [69.113.162.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: NP-Hardass) by smtp.gentoo.org (Postfix) with ESMTPSA id A682533D3CE for ; Mon, 10 Apr 2017 19:04:47 +0000 (UTC) Subject: Re: [gentoo-dev] News item: app-emulation/wine split and slotting To: gentoo-dev@lists.gentoo.org References: <5e54dd75-a564-9bba-0c21-519eff0b4dfa@gentoo.org> <1491845492.1661.4.camel@gentoo.org> <8de9edea-7de4-a26d-f2ce-25db27e57bfe@gentoo.org> <1491848222.1661.12.camel@gentoo.org> From: NP-Hardass Openpgp: id=862040BE422755F27FDE13D5671C52F118F89C67; url=https://sks-keyservers.net/pks/lookup?op=get&search=0x671C52F118F89C67 Message-ID: <0bf92d83-f4d6-813c-ac20-a0b0def53d48@gentoo.org> Date: Mon, 10 Apr 2017 15:04:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1491848222.1661.12.camel@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kn6hO4XSBGF3FI1tkBoPk7I6HIaihwU3X" X-Archives-Salt: 02c6073c-8976-4f28-afe4-ccedd9e5e5fd X-Archives-Hash: 19d567f6090e9606956c5a14731666ef This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kn6hO4XSBGF3FI1tkBoPk7I6HIaihwU3X Content-Type: multipart/mixed; boundary="fJEqvglJdRDS1aAE3t6W6KvK6p0ij5K3J"; protected-headers="v1" From: NP-Hardass To: gentoo-dev@lists.gentoo.org Message-ID: <0bf92d83-f4d6-813c-ac20-a0b0def53d48@gentoo.org> Subject: Re: [gentoo-dev] News item: app-emulation/wine split and slotting References: <5e54dd75-a564-9bba-0c21-519eff0b4dfa@gentoo.org> <1491845492.1661.4.camel@gentoo.org> <8de9edea-7de4-a26d-f2ce-25db27e57bfe@gentoo.org> <1491848222.1661.12.camel@gentoo.org> In-Reply-To: <1491848222.1661.12.camel@gentoo.org> --fJEqvglJdRDS1aAE3t6W6KvK6p0ij5K3J Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/10/2017 02:17 PM, Micha=C5=82 G=C3=B3rny wrote: > On pon, 2017-04-10 at 13:52 -0400, NP-Hardass wrote: >> On 04/10/2017 01:31 PM, Micha=C5=82 G=C3=B3rny 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 hav= e >> multiple versions installed side by side (=3Dwine-vanilla-2.1 and >> =3Dwine-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 avo= id >> accidental redundancy) The two primary uses of any *should* be using >> multiple patchsets simultaneously (any[d3d9,staging]) and using any t= o >> 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)) >=20 > 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 particula= r > set of changes is usually applied to mainline or regularly rebased > against mainline but without full separation (kernel patchsets, bitcoin= > patches); [...] >=20 > 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. >=20 > Separate packages are used e.g. for different kernel patch sets. This > has the following advantages: >=20 > 2a1. more clear distinction between base and patched version, >=20 > 2a2. cleaner when patch sets imply major changes, e.g. when some > of the USE flags apply to patched version only, >=20 > 2a3. the packages can be bumped independently, without worrying that > the patch set has not been updated yet. >=20 > A single package with USE flags is used e.g. for openssl (hpn patch > set), bitcoincore (ljr patch set). This has the following advantages: >=20 > 2b1. available patches are cleanly exposed via USE flags, >=20 > 2b2. multiple patch sets can be combined in a single package, >=20 > 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). >=20 > 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 yo= u > have to set for 4 packages consistently, and remember to update them or= > switching between variants is going to result in an accidental differen= t > build. >=20 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 cove= r > all the bases? ;-) >=20 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) --=20 NP-Hardass [1] https://archives.gentoo.org/gentoo-dev/message/18d271b991a4088675444939ce= 1ee1a1 --fJEqvglJdRDS1aAE3t6W6KvK6p0ij5K3J-- --kn6hO4XSBGF3FI1tkBoPk7I6HIaihwU3X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEv526yLNI+t7RHfJZHNlBHbKvGPsFAljr10sACgkQHNlBHbKv GPtRPhAAklUHSk+2o6EQ7/cuZiffdX4KmXxRQkDCe2yOxQuT+HgP390ViLSBQdU5 fd8B7Rg0eMQ2W5dlcO7u+AyBCQKdp2Qh5AdQTmK0+WVqiL8d0FHEZ6KzMD3p0dH/ HCEn382Zjawuiw116YJ5xWzmh1BSjcXPQJhEsQ22CFfhQli15yI4RUr3H7f8c+vF n3pBO58M49fY4mBg/AbJ5M+FlUbpieKUWQR0OHkFQAcOggP5r1iUUR2oRrR3WQ/x JEEqBkW3MQNiDOfZlt8poSrTe43Qt70dgEwePdC7ddQ3pefN62yDw1J/I4+63F8b 4mJtdyb/OBqdiA4eeIbHGy2+LHQ5ujgllXXBWhyRvlGFcMxaC611gHTpfgzoaLSr zvjDKCKaveXn/Y/O6Ubmo1ZcCSOFQNobcvi/GGqEbSHYvohzYLbV14ykww2m2hmx /YyVt+ijTvUvmkPSb0rdnJDWBXQDn/ndIy4s23fSM9ue6F9vcLLmUQAuX0lHW+q7 4vU+sRs4q5FyBR0inPF+01PR3uv93UUfioCxhaX9CNA/MaW9l6QuN2szuFoeIQwN fi63PGhURX5hv7SBAl7foANP80DaG08Pq3wN9PmnZhJ/4nB24ZOVQjrjiX4Kh1mk jsVyzeGblIrwADO5Nf0tQLw6e6d5cvTRkqOBfnC/5bv3hGlTyME= =S4Rr -----END PGP SIGNATURE----- --kn6hO4XSBGF3FI1tkBoPk7I6HIaihwU3X--