| 1 |
El mar, 20-09-2011 a las 01:14 +0300, Alex Alexander escribió: |
| 2 |
> EAPI in profiles and the -live version suffix are some of the improvements |
| 3 |
> many people would like to see in the tree. Unfortunately, the risk of breaking |
| 4 |
> systems with old versions of portage has been too high, holding evolution |
| 5 |
> back. |
| 6 |
> |
| 7 |
> I've been thinking about a way to solve this that would be easy to implement, |
| 8 |
> without any significant compromises and one thing comes to mind: |
| 9 |
> |
| 10 |
> Manipulation of the SYNC variable (i.e. rsync module), |
| 11 |
> combined with tree snapshots. |
| 12 |
> |
| 13 |
> At the moment, all systems have a SYNC line similar to this: |
| 14 |
> |
| 15 |
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" |
| 16 |
> |
| 17 |
> My idea is simple. When incompatible changes have to be introduced to the |
| 18 |
> tree, push a new version of portage that includes support for all the new |
| 19 |
> features we want to provide. |
| 20 |
> |
| 21 |
> Then, freeze the tree and clone it into a revbumped rsync module, i.e. |
| 22 |
> |
| 23 |
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1" |
| 24 |
> |
| 25 |
> That way the last update provided by the old tree will be the updated portage |
| 26 |
> package, which will be aware of the SYNC change. |
| 27 |
> |
| 28 |
> After the user installs that update, every subsequent emerge run will print a |
| 29 |
> fat red warning telling the user that the tree has been revbumped. |
| 30 |
> |
| 31 |
> It will then provide instructions on how to update the make.conf/SYNC |
| 32 |
> and a Y/N prompt to fix it itself. It could even do it automatically, |
| 33 |
> but that's debatable. |
| 34 |
> |
| 35 |
> By doing this we can be sure that any user using the revbumped SYNC have |
| 36 |
> an up-to-date portage (if they cheated, well, that's their problem), allowing |
| 37 |
> us to use all the new features provided by the latest version of portage. |
| 38 |
> |
| 39 |
> For the above to work, we would require at least |
| 40 |
> - support for multiple rsync modules pointing to different trees |
| 41 |
> [also in mirrors] |
| 42 |
> - a way to freeze the current state of the tree for the current rsync module |
| 43 |
> and push future updates to a revbumped rsync module. |
| 44 |
> - update our portage-snapshot tools to use the latest rsync module. |
| 45 |
> - other things I'm probably forgetting right now |
| 46 |
> |
| 47 |
> I'm not sure how much work would be required to make our current |
| 48 |
> infrastructure support this, the infra people could shed some light on |
| 49 |
> this. |
| 50 |
> |
| 51 |
> The idea is to use this system sparingly, only when we need to push big |
| 52 |
> changes that can't be supplied through an EAPI. Another example would be a |
| 53 |
> change that would break the upgrade path. By freezing the tree at the right |
| 54 |
> moment, we can be sure that the users will follow a known upgrade path |
| 55 |
> that works. |
| 56 |
> |
| 57 |
> Please keep in mind that my solution isn't trying to be the best thing |
| 58 |
> possible. Instead, I'm aiming for something that would do the job and would be |
| 59 |
> implemented in a realistic timeframe. |
| 60 |
> |
| 61 |
> What do you guys think? |
| 62 |
|
| 63 |
I haven't ever tried it but, what would occur if that people with really |
| 64 |
updated systems simply unpack an updated stage3 tarball in their / and, |
| 65 |
later, try to update? |
Archives