[gentoo-dev] Re: Avoiding rebuilds
Steven J. Long sl...@rathaus.eclipse.co.uk wrote: collect your thoughts into a forum post You are right: Not everybody on this list is interested in all technical details, so it is perhaps better to shift this discussion to the forums. I have opened the topic https://forums.gentoo.org/viewtopic-p-7593700.html#7593700 with a summary of the various suggestions (and a very rough sketch of their advantages/disadvantages). Sounds like something that repoman could check, once a GLEP and impl are in place. The problem I meant is that repoman is no able to check it: It can be completely reasonable that the value of that metadata variable is unchanged, that is, repoman should not even spit a warning in this case. Unless one adds an artificial mechanism (like encoding the revision into the variable name or variable content) which *forces* the maintainer to change/check that variable. But any such mechanism I can think of is inconvenient and possibly confusing.
[gentoo-dev] Re: Avoiding rebuilds
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 exactly what I do quite frequently.. so thanks
[gentoo-dev] Re: Avoiding rebuilds
On Mon, Jul 28, 2014 at 05:49:07AM +, Martin Vaeth wrote:
hasufell hasuf...@gentoo.org wrote:
Ulrich Mueller:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
As already mentioned, -r1.1 is only one of several possible ways
how to achieve the same aim; I am not speaking in favour for a
particular method.
Sure. As dolsen prefix is using it, even if this weren't better done
as metadata.
The -r1.1 method has the advantage of being simple and transparent
to the user and developer. Other approaches have other advantages:
Instead, one could introduce a variable INSTALL_VERSION that would
(It would have to be a variable stored in the metadata/ cache
and thus also would only work with a new API, but these are only
technical details.)
Agreed again, there's far too much conflabation of EAPI vs impl round here.
Not helped by the obfuscatory troll you've had the mispleasure to encounter.
Think of it as an initiation.. ;-)
default to ${PVR} but could be set to the version of a previous ebuild
instead. The PM could compare it against INSTALL_VERSION in the VDB
and skip build and installation if versions match.
It should be a list and have empty default (*never* including the
version itself), but these are also technical details.
This solution would have the advantage that you could specify
*full* versions and thus have even more fine-grained control when
recompilations are necessary. One could also allow specify version
ranges, slots, overlays, etc., perhaps even make the behaviour
dependent of USE-flags, as you already mentioned, all
similarl to current DEPEND syntax.
The disadvantage is that it is slightly more work than -r1.1,
less transparent, and easily overlooked to remove for a version bump,
causing issues like these:
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 REPLACES_VERSION, or
w/e the primadonna will allow, since we're still feeding him goats..
Perhaps doubt he'll want to pluralise it, in that tedious nu-skool way
of his. More likely he'll just use anything we discuss as an excuse
for more FUD.
Regards,
steveL
PS: Now you know just why..
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: Avoiding rebuilds
Steven J. Long sl...@rathaus.eclipse.co.uk wrote: 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: 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. 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]).
Re: [gentoo-dev] Re: Avoiding rebuilds
On Mon, 28 Jul 2014 05:49:07 + (UTC)
Martin Vaeth mar...@mvath.de wrote:
hasufell hasuf...@gentoo.org wrote:
Ulrich Mueller:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
As already mentioned, -r1.1 is only one of several possible ways
how to achieve the same aim; I am not speaking in favour for a
particular method.
The -r1.1 method has the advantage of being simple and transparent
to the user and developer. Other approaches have other advantages:
Instead, one could introduce a variable INSTALL_VERSION that would
(It would have to be a variable stored in the metadata/ cache
and thus also would only work with a new API, but these are only
technical details.)
default to ${PVR} but could be set to the version of a previous
ebuild instead. The PM could compare it against INSTALL_VERSION in
the VDB and skip build and installation if versions match.
It should be a list and have empty default (*never* including the
version itself), but these are also technical details.
This solution would have the advantage that you could specify
*full* versions and thus have even more fine-grained control when
recompilations are necessary. One could also allow specify version
ranges, slots, overlays, etc., perhaps even make the behaviour
dependent of USE-flags, as you already mentioned, all
similarl to current DEPEND syntax.
The disadvantage is that it is slightly more work than -r1.1,
less transparent, and easily overlooked to remove for a version bump,
causing issues like these:
It will probably also cause confusion for comaintainers and
collaborators, especially when INSTALL_VERSION points to a version
that has already been removed.
I haven't had the energy to read all the mails over all the dynamic
deps thread...
the -r1.1 syntax has been in use by the prefix since early in it's
existence. I haven't kept track, but they may have finally done away
with it.
There are many other problems with using that syntax, namely most other
tools are not compatible with it, so more than just portage needs to be
modified. Adding that syntax to ebuilds will cause disruptions and bugs
for years to come.
So, please, forget about this syntax as a viable solution.
--
Brian Dolbec dolsen
[gentoo-dev] Re: Avoiding rebuilds
hasufell hasuf...@gentoo.org wrote:
Ulrich Mueller:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
As already mentioned, -r1.1 is only one of several possible ways
how to achieve the same aim; I am not speaking in favour for a
particular method.
The -r1.1 method has the advantage of being simple and transparent
to the user and developer. Other approaches have other advantages:
Instead, one could introduce a variable INSTALL_VERSION that would
(It would have to be a variable stored in the metadata/ cache
and thus also would only work with a new API, but these are only
technical details.)
default to ${PVR} but could be set to the version of a previous ebuild
instead. The PM could compare it against INSTALL_VERSION in the VDB
and skip build and installation if versions match.
It should be a list and have empty default (*never* including the
version itself), but these are also technical details.
This solution would have the advantage that you could specify
*full* versions and thus have even more fine-grained control when
recompilations are necessary. One could also allow specify version
ranges, slots, overlays, etc., perhaps even make the behaviour
dependent of USE-flags, as you already mentioned, all
similarl to current DEPEND syntax.
The disadvantage is that it is slightly more work than -r1.1,
less transparent, and easily overlooked to remove for a version bump,
causing issues like these:
It will probably also cause confusion for comaintainers and
collaborators, especially when INSTALL_VERSION points to a version that
has already been removed.
