EAPI in profiles and the -live version suffix are some of the improvements many people would like to see in the tree. Unfortunately, the risk of breaking systems with old versions of portage has been too high, holding evolution back.
I've been thinking about a way to solve this that would be easy to implement, without any significant compromises and one thing comes to mind: Manipulation of the SYNC variable (i.e. rsync module), combined with tree snapshots. At the moment, all systems have a SYNC line similar to this: SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" My idea is simple. When incompatible changes have to be introduced to the tree, push a new version of portage that includes support for all the new features we want to provide. Then, freeze the tree and clone it into a revbumped rsync module, i.e. SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1" That way the last update provided by the old tree will be the updated portage package, which will be aware of the SYNC change. After the user installs that update, every subsequent emerge run will print a fat red warning telling the user that the tree has been revbumped. It will then provide instructions on how to update the make.conf/SYNC and a Y/N prompt to fix it itself. It could even do it automatically, but that's debatable. By doing this we can be sure that any user using the revbumped SYNC have an up-to-date portage (if they cheated, well, that's their problem), allowing us to use all the new features provided by the latest version of portage. For the above to work, we would require at least - support for multiple rsync modules pointing to different trees [also in mirrors] - a way to freeze the current state of the tree for the current rsync module and push future updates to a revbumped rsync module. - update our portage-snapshot tools to use the latest rsync module. - other things I'm probably forgetting right now I'm not sure how much work would be required to make our current infrastructure support this, the infra people could shed some light on this. The idea is to use this system sparingly, only when we need to push big changes that can't be supplied through an EAPI. Another example would be a change that would break the upgrade path. By freezing the tree at the right moment, we can be sure that the users will follow a known upgrade path that works. Please keep in mind that my solution isn't trying to be the best thing possible. Instead, I'm aiming for something that would do the job and would be implemented in a realistic timeframe. What do you guys think? -- Alex Alexander | wired + Gentoo Linux Developer ++ www.linuxized.com
signature.asc
Description: Digital signature
