Gentoo Archives: gentoo-dev

From: Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
Date: Sun, 24 Jul 2016 07:11:23
Message-Id: 20160724081109.08933bad@snowblower
In Reply to: Re: [gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA by Andrew Savchenko
1 On Sun, 24 Jul 2016 10:05:23 +0300
2 Andrew Savchenko <bircoph@g.o> wrote:
3 > I agree with you, but REPLACING_VERSIONS has nothing to do with
4 > such recovery.
5
6 Yes, it does. Specifically, what we want is for developers to get into
7 the habit of writing safe, clean code, even if they think they don't
8 need to care about it in some particular situation because they can't
9 think of how it would go wrong. It's the same as getting into the habit
10 of sticking || die on things.
11
12 > 1) It appeared only in EAPI 4, approved on 2011-01-17. Recovery
13 > from hardware crashes forked well long before.
14
15 Before this, you could use has_version in pkg_*, and it would tell you
16 the *old* version of the package that was installed. The phase order
17 changed a while ago, and broke this, so REPLACING_VERSIONS was the
18 replacement.
19
20 Again, the situation is complicated, there's a lot of messy history
21 behind this, and if you don't know it all, just do what the spec says
22 and stop wasting everyone's time by arguing.
23
24 > 2) If you will look into the tree, in the absolute majority of cases
25 > REPLACING_VERSIONS is being used to determine whether informational
26 > messages should be shown to a user or not. Such messages usually
27 > include some upgrade hints or howtos; and REPLACING_VERSIONS check
28 > is required to avoid showing them to unaffected users. It has
29 > absolutely nothing to do with the error recovery done by PM itself.
30
31 Don't get into the habit of writing code that makes unnecessary
32 assumptions that will come back and screw users over in unexpected
33 situations. It's easy to do this the right way, so at this point I can
34 only conclude that you're persisting in trying to do it wrong just to
35 avoid admitting that you made a mistake from ignorance. It's OK to be
36 wrong sometimes (and this is why code review exists), but it's not OK
37 to continue to argue that you were right out of stubbornness.
38
39 --
40 Ciaran McCreesh