On Wednesday 16 February 2005 12:07, Brian Harring wrote: > On Wed, Feb 16, 2005 at 11:54:47AM +0100, Gregorio Guidi wrote: > > Another possibility is to make this automatic: when creating the cache, > > portage can recognize that new eclasses were used and add the > > ">=sys-apps/portage-x.y" atom to DEPEND. > > Possible I spose, but I'm not much for adding basically a hack to portage > :) I'd rather have it handled in the ebuilds, since theres no point in > requiring a newer version of portage if the ebuild still uses the old > eclasses (fex).
Adding portage as a depedency in ebuilds can result in circular dependencies that can even break emerge system. To give a real world example; sys-apps/portage needs dev-lang/python dev-lang/python needs dev-libs/openssl dev-libs/openssl needs dev-lang/perl dev-lang/perl needs sys-apps/portage Features are being added to portage that can create a lot of ebuilds with a portage dependency (USE-based DEPEND atom type, default USE settings on a per package-version basis via IUSE, etc.). Needless to say that this will increase the changes on circular dependencies a lot. Why not make it a policy (and hardcoded in portage) that if you have a tree from x point in time you must use the stable marked portage from that x point in time? What do you think? -- [email protected] mailing list
