| 1 |
Ok, the subject might be confusing, so let me explain this a bit: |
| 2 |
|
| 3 |
Whenever we want/need to make structural changes to the tree that are |
| 4 |
going to break backwards compability we have a serious problem (see |
| 5 |
GLEP 44 in case you don't know about it). To reduce the impact of that |
| 6 |
problem I've got the idea to make the tree itself (so not any |
| 7 |
particular ebuild or profile) DEPEND on a minimal portage version, |
| 8 |
which the users would be forced to upgrade to (maybe with an override) |
| 9 |
before they can do anything else (with the exception of --sync). |
| 10 |
Manifest2 is one example for such a situation, another one is the |
| 11 |
request to not create manifest entries for ChangeLog and metadata.xml |
| 12 |
anymore (needs >=2.0.51.20 on user side). |
| 13 |
Don't really like this idea myself, but somthing needs to be done to at |
| 14 |
least reduce the problem, having to wait years for old portage versions |
| 15 |
to (almost) vanish can't be a permanent solution. |
| 16 |
|
| 17 |
Also not talking about implementation details yet, just after comments |
| 18 |
about the general idea of forced portage updates. |
| 19 |
|
| 20 |
And just in case anybody wonders: this cannot be fixed with EAPI or |
| 21 |
adding a portage dep on packages as those only take effect when the |
| 22 |
ebuild is already parsed while the mentioned problems occur much |
| 23 |
earlier. |
| 24 |
|
| 25 |
Marius |
| 26 |
|
| 27 |
-- |
| 28 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 29 |
|
| 30 |
In the beginning, there was nothing. And God said, 'Let there be |
| 31 |
Light.' And there was still nothing, but you could see a bit better. |
Archives