Ciaran McCreesh wrote:
No. Really. Again. You've been steadily talking nonsense on this whole
issue. Please step back, start again and clearly and concisely explain
in coherent English how you solve the simple example I gave earlier in
the thread. I am far from the only person who hasn't managed to work
out your explanation of this simple case so far.
Let try to clarify:
main problem:
- have the possibility to track upstream w/out having to take a manual
snapshot of their sources, but having portage automatically fetch them
from their tree.
current situation:
- we have some eclasses that on unpack phase fetch the sources from the
upstream server, prepare them and then the usual ebuild process follows.
- in order to make an ebuild using those eclasses be valued as the
highest possible, the simplest solution had been give it a version "high
enough", namely -9999. That makes simple track a single tree per package.
- The same could be done with any version component in order to try to
track multiple instances, so to track what will be the next 1.5 version,
somebody could create an ebuild as 1.4.9999 or 1.5_pre9999, 9999 being
an arbitrary big number.
-scm proposal:
- use a component version that makes whatever before it valued as "the
highest within that component", likely -r or _p do, that includes the
case "the highest version in absolute" in order to arbitrary decide an
"high enough" value, namely -9999.
- from what you can find in the glep, the change is apparently purely
cosmetic beside the hinted but not expressed possibilities having
portage fully aware those ebuild manage something "live" could give.
live-properity proposal:
- have a property to make portage aware that the ebuild is using live
sources.
- it doesn't add components to the ebuild version but just marks the
ebuild. So this proposal aims to improve portage internal management but
doesn't add or detract anything regarding version resolution.
live-template proposal:
- you still have a new version component, in this case either ".live" or
"_live", but in the template.
- it isn't used directly in resolution but it generates automatically a
normal version that get resolved as usual.
- tries to make sure there is a way to get reproducible results
regarding installed packages by embedding the informations to get again
the same sources. So you can also re-emerge the very same package again
you emerged it once since it has a defined version number.
- tries to give developers willing to track upstream and then provide
snapshots the ability to do that automatically.
I hope that is what the various proponents meant with their proposals
and that's clear enough.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
