Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Avoiding rebuilds
Date: Sat, 02 Aug 2014 12:53:30
In Reply to: [gentoo-dev] Re: Avoiding rebuilds by Martin Vaeth
1 Martin Vaeth wrote:
2 > Steven J. Long wrote:
3 Please set your client not to include email addresses (for publically
4 web-archived newsgroups.)
6 > >> > It will probably also cause confusion for comaintainers and
7 > >> > collaborators, especially when INSTALL_VERSION points to a version
8 > >> > that has already been removed.
9 > >
10 > > So use another name that can't be confused.
11 >
12 > Perhaps there is a misunderstanding: I did not understand that the
13 > confusion is caused by the name, but by the lack of information
14 > about its entries:
16 Yeah, perhaps that's a language thing then. "install version" in English
17 implies you're installing it currently, and the removal conflicts in
18 semantic terms. It just doesn't feel right.
20 > For instance, if you bump a version, you must never forget to
21 > check whether this variable needs to be updated.
22 > Moreover, if you want to update that variable, you should
23 > understand precisely why which version is listed here
24 > in order to decide whether a recompile from that version
25 > might be needed with the current bump or not.
26 > This decision is not necessarily easy if the corresponding
27 > referred ebuilds are already in the CVS attic.
29 My instant thought there is that this is a maintainer decision. I agree
30 the consequences of getting it wrong aren't good. What about giving it
31 a working-name of CHANGE_VDB?
33 Regardless of how it's implemented the PM has to have an installed pkg
34 db; for instance istr portage can share a sqlite db with eix.
35 Irrespective of the impl or its configuration, the concept of a pkg db
36 is hardly contentious; it's central to the domain, and implicit in
37 REPLACING_VERSIONS and REPLACED_BY_VERSION. Based on the long prior
38 thread, I'd say there's consensus for the need in very specific
39 circumstances to change vdb entries, ideally at the granularity of the
40 ebuild; and it's better if this isn't part of the normal dep-calc.
42 Calling it that directly is simpler, and it stands out as something
43 both unusual and changing the vdb, which any Gentoo admin is familiar
44 with. The imperative form is in line with what is going to happen:
45 we're telling the mangler to change the vdb, for matching atoms, if
46 it installs this package. It could end up CHANGE_PKG_DB instead;
47 sticking an E on the front, or making it into some obfuscated C++
48 style name, that can be bikeshedded after it's actually specified.
50 However as you've seen, it's a lot harder to have a focussed discussion
51 on the dev ML than it is on the forums. Having waded through that thread
52 on the web[1] I have no wish ever to do it again, nor would I inflict it
53 on someone trying to catch up with the thinking behind changes in the
54 future. Indeed it would be quite embarrassing in the context of
55 attracting new people, as has happened before.
57 At this stage though, I cannot say that I have any sort of overall grasp
58 on the various constraints you've outlined, based on the requirements
59 you and others have specified. Could I ask therefore that you collect
60 your thoughts into a forum post, where we can collaborate without the
61 flak-storm of agenda-driven political FUD poisoning the discussion?
62 It's much easier since the OP is always at the top of the thread, and
63 we can push the content block to a wiki page once we're done, and go
64 for a GLEP from there, after wider discussion.
66 While I could go back over the thread and try to pull out your thoughts,
67 it would take me a long time, be painfully tedious (ie I ain't going to,
68 come what may;) and not consistent, nor as comprehensive as you simply
69 grabbing it from your mailbox, and tidying up what you're thinking.
71 If you want some help making it more fluent English, feel free to email
72 me off-list with a first draft, assuming this is okay with you.
74 > Of course, if in doubt, it is a safe strategy to always
75 > remove that variable (it can only cause redundant compilation,
76 > while it can be fatal if you leave a version falsely).
77 >
78 > Therefore, an automatism to "forget" this variable automatically
79 > if not changed would be preferrable, but one would need a mechanism
80 > for this (I have only some strange ideas for such a mechanisms:
81 > One could encode the current ebuild version into the name of
82 > that variable; or one could require that the current version
83 > is the first entry in this variable [although, semanatically,
84 > it is ignored and just serves as a "proof" that the ebuild
85 > maintainer checked that variable]).
87 Sounds like something that repoman could check, once a GLEP and impl
88 are in place. By then it should be much easier to add, and maintain,
89 a specific check as the repoman code is currently being modularised.
91 Anyhow, good to have a man of your experience and approach contributing
92 to the dev discussion at last. Plenty of devs use eix as you may have
93 seen in various posts; I can tell you from IRC that knowing its
94 switches is almost seen as black-magic sometimes ;p
96 I don't ofc: I just tell them to post on the forums and get the info
97 from you, if they can't work out the manpages, which as you know is
98 exactly what I do quite frequently.. so thanks for the support as
99 well as the excellent util.
101 Regards,
102 steveL.
104 [1]
105 --
106 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


Subject Author
[gentoo-dev] Re: Avoiding rebuilds Martin Vaeth <martin@×××××.de>