Gentoo Archives: gentoo-dev

From: Michael Palimaka <kensington@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Revisions for USE flag changes
Date: Sat, 12 Aug 2017 04:22:47
Message-Id: 99777392-a964-3865-c26b-ae47b443aa13@gentoo.org
In Reply to: [gentoo-dev] Revisions for USE flag changes by Michael Orlitzky
1 On 08/12/2017 09:50 AM, Michael Orlitzky wrote:
2 > Q. But what about the rebuilds?
3 >
4 > For most packages, the rebuilds simply don't matter. Unless you're
5 > the maintainer of libreoffice, firefox, chromium, etc. -- just do the
6 > revision and forget about the (quick) rebuilds.
7
8 I really wish people would stop trotting out this false argument. Not
9 everyone has the latest and greatest hardware. Rebuilds have a real cost
10 to end users and as such we should use them wisely.
11
12 > We tell everyone to use --changed-use and --newuse if they want
13 > things to work, so they were probably going to rebuild anyway.
14
15 Who tells everyone to use these flags and where? I never use these flags
16 day-to-day, only if I need that specific functionality for that reason
17
18 > Q. But what if I maintain firefox, and I need to change IUSE?
19 >
20 > If the IUSE change isn't important, just make the new revision in a
21 > branch and wait to commit it later when there are more changes
22 > piled up. If it is important (like if its default value changes
23 > RDEPEND), then it would have required a revision anyway.
24
25 Please stop trying to force workflows on people. Using that same logic,
26 I can make the IUSE change in-place and it would be propagated in the
27 next version bump.
28
29 > Q. But I work on a team, and we can't all work in different branches.
30 >
31 > If you work on a massive package and if you're collaborating with
32 > others regularly, you can commit the new ebuild masked. This is
33 > annoying, but is an extremely rare combination of circumstances.
34
35 Again, let's not try and tell teams which workflow works best for them.
36
37 > == tl;dr ==
38 >
39 > We would be better off with respect to IUSE changes and revisions if we
40 > deleted the --changed-use and --newuse flags right now, and just
41 > required developers to revbump when changing IUSE.
42 >
43 > Package managers get simpler, documentation gets simpler, the user
44 > interface gets simpler, and behavior becomes more uniform and predictable.
45 >
46 > Please let me know what you think.
47
48 I disagree with this change because your proposed benefits don't hold up:
49
50 > * We can delete all of the PM code for --changed-use and --newuse and
51 > friends.
52
53 As pointed out by Brian, we still need at least --changed-use even if
54 IUSE changes in-place are banned.
55
56 > * The documentation becomes much simpler: revbump if IUSE changes.
57
58 We should base our policies around the cost / benefit of said policy,
59 not how many or few words we need to write in the devmanual about it.
60
61 > * Users can omit --newuse and --changed-use from their lives.
62
63 They already can.
64
65 > * All package managers now handle IUSE changes properly.
66
67 If you want to see consistent behaviour in how package manages handle
68 IUSE, I suggest sending patches for PMS. I don't see any problem in
69 portage/paludis/pkgcore handling things differently. That is the point
70 of having different package managers, after all.
71
72 > * emerge runs a bit faster.
73
74 Why will it run faster?

Replies

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