| 1 |
Ciaran McCreesh wrote: |
| 2 |
> No. Really. Again. You've been steadily talking nonsense on this whole |
| 3 |
> issue. Please step back, start again and clearly and concisely explain |
| 4 |
> in coherent English how you solve the simple example I gave earlier in |
| 5 |
> the thread. I am far from the only person who hasn't managed to work |
| 6 |
> out your explanation of this simple case so far. |
| 7 |
|
| 8 |
Let try to clarify: |
| 9 |
|
| 10 |
main problem: |
| 11 |
- have the possibility to track upstream w/out having to take a manual |
| 12 |
snapshot of their sources, but having portage automatically fetch them |
| 13 |
from their tree. |
| 14 |
|
| 15 |
current situation: |
| 16 |
- we have some eclasses that on unpack phase fetch the sources from the |
| 17 |
upstream server, prepare them and then the usual ebuild process follows. |
| 18 |
- in order to make an ebuild using those eclasses be valued as the |
| 19 |
highest possible, the simplest solution had been give it a version "high |
| 20 |
enough", namely -9999. That makes simple track a single tree per package. |
| 21 |
- The same could be done with any version component in order to try to |
| 22 |
track multiple instances, so to track what will be the next 1.5 version, |
| 23 |
somebody could create an ebuild as 1.4.9999 or 1.5_pre9999, 9999 being |
| 24 |
an arbitrary big number. |
| 25 |
|
| 26 |
-scm proposal: |
| 27 |
- use a component version that makes whatever before it valued as "the |
| 28 |
highest within that component", likely -r or _p do, that includes the |
| 29 |
case "the highest version in absolute" in order to arbitrary decide an |
| 30 |
"high enough" value, namely -9999. |
| 31 |
- from what you can find in the glep, the change is apparently purely |
| 32 |
cosmetic beside the hinted but not expressed possibilities having |
| 33 |
portage fully aware those ebuild manage something "live" could give. |
| 34 |
|
| 35 |
live-properity proposal: |
| 36 |
- have a property to make portage aware that the ebuild is using live |
| 37 |
sources. |
| 38 |
- it doesn't add components to the ebuild version but just marks the |
| 39 |
ebuild. So this proposal aims to improve portage internal management but |
| 40 |
doesn't add or detract anything regarding version resolution. |
| 41 |
|
| 42 |
live-template proposal: |
| 43 |
- you still have a new version component, in this case either ".live" or |
| 44 |
"_live", but in the template. |
| 45 |
- it isn't used directly in resolution but it generates automatically a |
| 46 |
normal version that get resolved as usual. |
| 47 |
- tries to make sure there is a way to get reproducible results |
| 48 |
regarding installed packages by embedding the informations to get again |
| 49 |
the same sources. So you can also re-emerge the very same package again |
| 50 |
you emerged it once since it has a defined version number. |
| 51 |
- tries to give developers willing to track upstream and then provide |
| 52 |
snapshots the ability to do that automatically. |
| 53 |
|
| 54 |
I hope that is what the various proponents meant with their proposals |
| 55 |
and that's clear enough. |
| 56 |
|
| 57 |
lu |
| 58 |
|
| 59 |
-- |
| 60 |
|
| 61 |
Luca Barbato |
| 62 |
Gentoo Council Member |
| 63 |
Gentoo/linux Gentoo/PPC |
| 64 |
http://dev.gentoo.org/~lu_zero |
Archives