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 B92E21396D0 for ; Sat, 12 Aug 2017 07:04:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 79C1EE0CB6; Sat, 12 Aug 2017 07:03:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 25959E0BEC for ; Sat, 12 Aug 2017 07:03:54 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 1D9F0341821; Sat, 12 Aug 2017 07:03:52 +0000 (UTC) Message-ID: <1502521423.1045.0.camel@gentoo.org> Subject: Re: [gentoo-dev] Revisions for USE flag changes From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sat, 12 Aug 2017 09:03:43 +0200 In-Reply-To: References: Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-fvdCWugLsHZf9c8qj9nk" X-Mailer: Evolution 3.22.6 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 X-Archives-Salt: 57a1ce89-a3fa-4962-9235-e8cee5504aeb X-Archives-Hash: a3ebd08a1939aa12a813697d17f69b10 --=-fvdCWugLsHZf9c8qj9nk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On pi=C4=85, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote: > We have a pull request for the devmanual that will update the revision > documentation; namely, when to create a new one: >=20 > https://github.com/gentoo/devmanual.gentoo.org/pull/67 >=20 > The comments bring up an issue that I think can benefit from some > hindsight. Specifically, the PR says that it's OK to change IUSE without > creating a revision, because users can use --changed-use to catch it. > My immediate objection to that was that --changed-use is specific to > Portage, but let's reflect on the status quo. >=20 >=20 > =3D=3D The situation now =3D=3D >=20 > 1 We tell everyone to update with either --newuse or --changed-use. >=20 > 2 Developers change IUSE without new revisions. >=20 > 3 To facilitate (1) and (2), Portage has the --changed-use and > --newuse flags. Paludis has a family of "--keep" options to avoid > reinstallation, e.g. --keep=3Dif-same-metadata. And pkgcore has its > own (different) --newuse flag. >=20 > 4 There is no specification for the features in (3), and each package > manager has taken a different approach. >=20 >=20 > The end result is that Portage users do see the changes made to IUSE > without a revision, but at a cost: >=20 > * They have to pass the "required" --changed-use or --newuse flags to > every command. >=20 > * The same cannot be said for users of other package managers. >=20 > * Lots of PM code exists to handle this stuff. >=20 > * Our documentation needs to describe the above (relatively) > complicated situation. >=20 >=20 > And with one notable benefit: >=20 > * We don't need to rename the ebuild to change IUSE, and in theory we > can control when rebuilds happen. >=20 >=20 >=20 > =3D=3D New revisions for USE flag changes =3D=3D >=20 > I suggest that in hindsight, we can do better. Suppose we require a new > revision for every change to IUSE. Then, >=20 > * We can delete all of the PM code for --changed-use and --newuse and > friends. >=20 > * The documentation becomes much simpler: revbump if IUSE changes. >=20 > * Users can omit --newuse and --changed-use from their lives. >=20 > * All package managers now handle IUSE changes properly. >=20 > * emerge runs a bit faster. >=20 > This has none of the downsides of the current approach. Of course, it > lacks that one benefit -- that you don't have to rename the ebuild when > you change IUSE. Now I'll try to convince you that the rename and > associated rebuilds aren't that big of a deal. >=20 >=20 > Q. But what about the rebuilds? >=20 > For most packages, the rebuilds simply don't matter. Unless you're > the maintainer of libreoffice, firefox, chromium, etc. -- just do the > revision and forget about the (quick) rebuilds. >=20 > We tell everyone to use --changed-use and --newuse if they want > things to work, so they were probably going to rebuild anyway. >=20 >=20 > Q. But what if I maintain firefox, and I need to change IUSE? >=20 > If the IUSE change isn't important, just make the new revision in a > branch and wait to commit it later when there are more changes > piled up. If it is important (like if its default value changes > RDEPEND), then it would have required a revision anyway. >=20 >=20 > Q. But I work on a team, and we can't all work in different branches. >=20 > If you work on a massive package and if you're collaborating with > others regularly, you can commit the new ebuild masked. This is > annoying, but is an extremely rare combination of circumstances. >=20 >=20 > =3D=3D tl;dr =3D=3D >=20 > We would be better off with respect to IUSE changes and revisions if we > deleted the --changed-use and --newuse flags right now, and just > required developers to revbump when changing IUSE. >=20 > Package managers get simpler, documentation gets simpler, the user > interface gets simpler, and behavior becomes more uniform and predictable= . >=20 > Please let me know what you think. >=20 Please provide some examples of recent in-place USE changes that benefit from revbumps. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-fvdCWugLsHZf9c8qj9nk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKmBAABCgCQFiEEbbsHzE8NrQbqCv5BsHoa6u+0Rk4FAlmOqE9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOHgcP/jJd9e9RfuZD2KXZZbOQFQig8HxqWB5S LRUivHOFlwDz+jJj3q5ae3mUV7/lOf7kNhA7l0dMxm4yjdlDOZN/aVQmzqaE7pou OtWnx9O5KFndO7lITn7OoavXpe/qjD+cNTKSo4o+5iq9zt3E0ErAq4jpqdapChVG sp/N+O7mYttKNURCxx3vJTp5v4mEEHl07PTnzLvuRjz72spvbk7tWX2QBi2i3eNX FSnbjJc2WaS6n+UaBkdJNkmvZOCIibB1yU6ETj9Vc4v2gzrKcQDPScvCHn+7TJzq bABHxz87PvNZcpJ3qKYGdofPlxZB7Yc43TH+0wf00zY6GNLs4IWLM8Qo4uFiZFjO 1bCHo5QwxaG5XkoOHGspiUgssSAlYpDItPFuraqFBaVkNkTfkvSKlrlHkeVjsOYI GRDlI/3zZQRsS4C+D1I5NK94YGp8y11HofDuOGqzHi6dcDdB1IZsk84v7MCgnLQF odEvaPCtaULIjqoc2D8/RHbPZkTorvQXRtvveKOFZUMhx5WVIhwy+cafjUK5DKJs Kn9v3HgM6HE87XdLMNWQ+u0SVR2gF7PIHj1xm1omnPTNV0TWZ7Rhy18lXLsgFLEK 4rJhqbvUKD/S0EhUubjFV3QjwpVr/HboU39aifn13IXqtrZe1Lld7sR+S9pWOphI ZZMu2F5gAw1R =Io0n -----END PGP SIGNATURE----- --=-fvdCWugLsHZf9c8qj9nk--