Martin Vaeth wrote:
> Steven J. Long wrote:
Please set your client not to include email addresses (for publically
web-archived newsgroups.)
> >> > It will probably also cause confusion for comaintainers and
> >> > collaborators, especially when INSTALL_VERSION points to a version
> >> > that has already been removed.
> >
> > So use another name that can't be confused.
>
> Perhaps there is a misunderstanding: I did not understand that the
> confusion is caused by the name, but by the lack of information
> about its entries:
Yeah, perhaps that's a language thing then. "install version" in English
implies you're installing it currently, and the removal conflicts in
semantic terms. It just doesn't feel right.
> For instance, if you bump a version, you must never forget to
> check whether this variable needs to be updated.
> Moreover, if you want to update that variable, you should
> understand precisely why which version is listed here
> in order to decide whether a recompile from that version
> might be needed with the current bump or not.
> This decision is not necessarily easy if the corresponding
> referred ebuilds are already in the CVS attic.
My instant thought there is that this is a maintainer decision. I agree
the consequences of getting it wrong aren't good. What about giving it
a working-name of CHANGE_VDB?
Regardless of how it's implemented the PM has to have an installed pkg
db; for instance istr portage can share a sqlite db with eix.
Irrespective of the impl or its configuration, the concept of a pkg db
is hardly contentious; it's central to the domain, and implicit in
REPLACING_VERSIONS and REPLACED_BY_VERSION. Based on the long prior
thread, I'd say there's consensus for the need in very specific
circumstances to change vdb entries, ideally at the granularity of the
ebuild; and it's better if this isn't part of the normal dep-calc.
Calling it that directly is simpler, and it stands out as something
both unusual and changing the vdb, which any Gentoo admin is familiar
with. The imperative form is in line with what is going to happen:
we're telling the mangler to change the vdb, for matching atoms, if
it installs this package. It could end up CHANGE_PKG_DB instead;
sticking an E on the front, or making it into some obfuscated C++
style name, that can be bikeshedded after it's actually specified.
However as you've seen, it's a lot harder to have a focussed discussion
on the dev ML than it is on the forums. Having waded through that thread
on the web[1] I have no wish ever to do it again, nor would I inflict it
on someone trying to catch up with the thinking behind changes in the
future. Indeed it would be quite embarrassing in the context of
attracting new people, as has happened before.
At this stage though, I cannot say that I have any sort of overall grasp
on the various constraints you've outlined, based on the requirements
you and others have specified. Could I ask therefore that you collect
your thoughts into a forum post, where we can collaborate without the
flak-storm of agenda-driven political FUD poisoning the discussion?
It's much easier since the OP is always at the top of the thread, and
we can push the content block to a wiki page once we're done, and go
for a GLEP from there, after wider discussion.
While I could go back over the thread and try to pull out your thoughts,
it would take me a long time, be painfully tedious (ie I ain't going to,
come what may;) and not consistent, nor as comprehensive as you simply
grabbing it from your mailbox, and tidying up what you're thinking.
If you want some help making it more fluent English, feel free to email
me off-list with a first draft, assuming this is okay with you.
> Of course, if in doubt, it is a safe strategy to always
> remove that variable (it can only cause redundant compilation,
> while it can be fatal if you leave a version falsely).
>
> Therefore, an automatism to "forget" this variable automatically
> if not changed would be preferrable, but one would need a mechanism
> for this (I have only some strange ideas for such a mechanisms:
> One could encode the current ebuild version into the name of
> that variable; or one could require that the current version
> is the first entry in this variable [although, semanatically,
> it is ignored and just serves as a "proof" that the ebuild
> maintainer checked that variable]).
Sounds like something that repoman could check, once a GLEP and impl
are in place. By then it should be much easier to add, and maintain,
a specific check as the repoman code is currently being modularised.
Anyhow, good to have a man of your experience and approach contributing
to the dev discussion at last. Plenty of devs use eix as you may have
seen in various posts; I can tell you from IRC that knowing its
switches is almost seen as black-magic sometimes ;p
I don't ofc: I just tell them to post on the forums and get the info
from you, if they can't work out the manpages, which as you know is
ex
