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.) |
5 |
|
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: |
15 |
|
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. |
19 |
|
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. |
28 |
|
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? |
32 |
|
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. |
41 |
|
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. |
49 |
|
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. |
56 |
|
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. |
65 |
|
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. |
70 |
|
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. |
73 |
|
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]). |
86 |
|
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. |
90 |
|
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 |
95 |
|
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. |
100 |
|
101 |
Regards, |
102 |
steveL. |
103 |
|
104 |
[1] http://marc.info/?t=140597147200005&r=9&w=2 |
105 |
-- |
106 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |