Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Revisions for USE flag changes
Date: Sat, 12 Aug 2017 07:04:01
Message-Id: 1502521423.1045.0.camel@gentoo.org
In Reply to: [gentoo-dev] Revisions for USE flag changes by Michael Orlitzky
1 On pią, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote:
2 > We have a pull request for the devmanual that will update the revision
3 > documentation; namely, when to create a new one:
4 >
5 > https://github.com/gentoo/devmanual.gentoo.org/pull/67
6 >
7 > The comments bring up an issue that I think can benefit from some
8 > hindsight. Specifically, the PR says that it's OK to change IUSE without
9 > creating a revision, because users can use --changed-use to catch it.
10 > My immediate objection to that was that --changed-use is specific to
11 > Portage, but let's reflect on the status quo.
12 >
13 >
14 > == The situation now ==
15 >
16 > 1 We tell everyone to update with either --newuse or --changed-use.
17 >
18 > 2 Developers change IUSE without new revisions.
19 >
20 > 3 To facilitate (1) and (2), Portage has the --changed-use and
21 > --newuse flags. Paludis has a family of "--keep" options to avoid
22 > reinstallation, e.g. --keep=if-same-metadata. And pkgcore has its
23 > own (different) --newuse flag.
24 >
25 > 4 There is no specification for the features in (3), and each package
26 > manager has taken a different approach.
27 >
28 >
29 > The end result is that Portage users do see the changes made to IUSE
30 > without a revision, but at a cost:
31 >
32 > * They have to pass the "required" --changed-use or --newuse flags to
33 > every command.
34 >
35 > * The same cannot be said for users of other package managers.
36 >
37 > * Lots of PM code exists to handle this stuff.
38 >
39 > * Our documentation needs to describe the above (relatively)
40 > complicated situation.
41 >
42 >
43 > And with one notable benefit:
44 >
45 > * We don't need to rename the ebuild to change IUSE, and in theory we
46 > can control when rebuilds happen.
47 >
48 >
49 >
50 > == New revisions for USE flag changes ==
51 >
52 > I suggest that in hindsight, we can do better. Suppose we require a new
53 > revision for every change to IUSE. Then,
54 >
55 > * We can delete all of the PM code for --changed-use and --newuse and
56 > friends.
57 >
58 > * The documentation becomes much simpler: revbump if IUSE changes.
59 >
60 > * Users can omit --newuse and --changed-use from their lives.
61 >
62 > * All package managers now handle IUSE changes properly.
63 >
64 > * emerge runs a bit faster.
65 >
66 > This has none of the downsides of the current approach. Of course, it
67 > lacks that one benefit -- that you don't have to rename the ebuild when
68 > you change IUSE. Now I'll try to convince you that the rename and
69 > associated rebuilds aren't that big of a deal.
70 >
71 >
72 > Q. But what about the rebuilds?
73 >
74 > For most packages, the rebuilds simply don't matter. Unless you're
75 > the maintainer of libreoffice, firefox, chromium, etc. -- just do the
76 > revision and forget about the (quick) rebuilds.
77 >
78 > We tell everyone to use --changed-use and --newuse if they want
79 > things to work, so they were probably going to rebuild anyway.
80 >
81 >
82 > Q. But what if I maintain firefox, and I need to change IUSE?
83 >
84 > If the IUSE change isn't important, just make the new revision in a
85 > branch and wait to commit it later when there are more changes
86 > piled up. If it is important (like if its default value changes
87 > RDEPEND), then it would have required a revision anyway.
88 >
89 >
90 > Q. But I work on a team, and we can't all work in different branches.
91 >
92 > If you work on a massive package and if you're collaborating with
93 > others regularly, you can commit the new ebuild masked. This is
94 > annoying, but is an extremely rare combination of circumstances.
95 >
96 >
97 > == tl;dr ==
98 >
99 > We would be better off with respect to IUSE changes and revisions if we
100 > deleted the --changed-use and --newuse flags right now, and just
101 > required developers to revbump when changing IUSE.
102 >
103 > Package managers get simpler, documentation gets simpler, the user
104 > interface gets simpler, and behavior becomes more uniform and predictable.
105 >
106 > Please let me know what you think.
107 >
108
109 Please provide some examples of recent in-place USE changes that benefit
110 from revbumps.
111
112 --
113 Best regards,
114 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Revisions for USE flag changes Michael Orlitzky <mjo@g.o>