On pią, 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: > > https://github.com/gentoo/devmanual.gentoo.org/pull/67 > > 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. > > > == The situation now == > > 1 We tell everyone to update with either --newuse or --changed-use. > > 2 Developers change IUSE without new revisions. > > 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=if-same-metadata. And pkgcore has its > own (different) --newuse flag. > > 4 There is no specification for the features in (3), and each package > manager has taken a different approach. > > > The end result is that Portage users do see the changes made to IUSE > without a revision, but at a cost: > > * They have to pass the "required" --changed-use or --newuse flags to > every command. > > * The same cannot be said for users of other package managers. > > * Lots of PM code exists to handle this stuff. > > * Our documentation needs to describe the above (relatively) > complicated situation. > > > And with one notable benefit: > > * We don't need to rename the ebuild to change IUSE, and in theory we > can control when rebuilds happen. > > > > == New revisions for USE flag changes == > > I suggest that in hindsight, we can do better. Suppose we require a new > revision for every change to IUSE. Then, > > * We can delete all of the PM code for --changed-use and --newuse and > friends. > > * The documentation becomes much simpler: revbump if IUSE changes. > > * Users can omit --newuse and --changed-use from their lives. > > * All package managers now handle IUSE changes properly. > > * emerge runs a bit faster. > > 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. > > > Q. But what about the rebuilds? > > 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. > > We tell everyone to use --changed-use and --newuse if they want > things to work, so they were probably going to rebuild anyway. > > > Q. But what if I maintain firefox, and I need to change IUSE? > > 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. > > > Q. But I work on a team, and we can't all work in different branches. > > 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. > > > == tl;dr == > > 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. > > Package managers get simpler, documentation gets simpler, the user > interface gets simpler, and behavior becomes more uniform and predictable. > > Please let me know what you think. >
Please provide some examples of recent in-place USE changes that benefit from revbumps. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
