| 1 |
On Mon, 2005-12-19 at 17:49 +0100, Marius Mauch wrote: |
| 2 |
> Ok, the subject might be confusing, so let me explain this a bit: |
| 3 |
> |
| 4 |
> Whenever we want/need to make structural changes to the tree that are |
| 5 |
> going to break backwards compability we have a serious problem (see |
| 6 |
> GLEP 44 in case you don't know about it). To reduce the impact of that |
| 7 |
> problem I've got the idea to make the tree itself (so not any |
| 8 |
> particular ebuild or profile) DEPEND on a minimal portage version, |
| 9 |
Makes syncing a bit more complicated. |
| 10 |
Downside: potentially more problems |
| 11 |
Upside: if there's a disruptive change people will at all times have a |
| 12 |
working system (just think about stacked profiles :-) ) |
| 13 |
|
| 14 |
> which the users would be forced to upgrade to (maybe with an override) |
| 15 |
> before they can do anything else (with the exception of --sync). |
| 16 |
Or you have a "version file" transferred by rsync (like timestamp) |
| 17 |
When version > portage version: fetch a static portage tree from a known |
| 18 |
location (mirror://portage-update-version-N.tbz2 or something) |
| 19 |
(emerge-delta-webrsync to the rescue!) |
| 20 |
> Manifest2 is one example for such a situation, another one is the |
| 21 |
> request to not create manifest entries for ChangeLog and metadata.xml |
| 22 |
> anymore (needs >=2.0.51.20 on user side). |
| 23 |
> Don't really like this idea myself, but somthing needs to be done to at |
| 24 |
> least reduce the problem, having to wait years for old portage versions |
| 25 |
> to (almost) vanish can't be a permanent solution. |
| 26 |
I don't like it, but unless portage is smart enough to self-update before anything else ... |
| 27 |
|
| 28 |
> Also not talking about implementation details yet, just after comments |
| 29 |
> about the general idea of forced portage updates. |
| 30 |
If documented properly and guaranteed to work for at least n months after a format change I like it |
| 31 |
(But I guess iterative updates should work "forever" as long as all |
| 32 |
files still exist) |
| 33 |
|
| 34 |
> And just in case anybody wonders: this cannot be fixed with EAPI or |
| 35 |
> adding a portage dep on packages as those only take effect when the |
| 36 |
> ebuild is already parsed while the mentioned problems occur much |
| 37 |
> earlier. |
| 38 |
Thanks for bringing it up for discussion! |
| 39 |
|
| 40 |
Patrick |
| 41 |
-- |
| 42 |
Stand still, and let the rest of the universe move |
Archives