-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carsten Lohrke wrote: > On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote: >> ~ * The meaning of the !atom blocker syntax now implies that >> ~ temporary simultaneous installation of conflicting packages is >> ~ allowed [3]. >> >> ~ * A new !!atom blocker syntax is now supported, for use in special >> ~ cases in which temporary simultaneous installation of conflicting >> ~ packages should not be allowed. > > I didn't really look into the issues, intended to be resolved with this, but > I'm somewhat suspecious that this is merely a hack around inaccurate > dependency listing in ebuilds on the one side and Portage's dependency > resolver issues on the other.
Well, I'm open to alternative suggestions. Please see the previous email in which I've attempted to explain the reasoning for the given approach [1]. It seems to me that this approach is well suited for solving cases in which temporary simultaneous installation of blocking packages is needed. > What I do strongly oppose is changing the meaning of the '!' symbol, as > blockers, which should remain real blockers will not be adjusted by us, when > changing an ebuild to EAPI 2++ in every case, since we're humans after all. > So, if you implement this, keep '!' as is and find another symbol for > these "soft" blockers. Again, please see my previous email on this subject [1]. The reason that I think we should change the meaning of the '!' symbol is that the majority of existing EAPI 0 or 1 blockers appear to fit the new meaning already. So, we'll only have to use the new !!atom syntax for special cases in which temporary simultaneous installation of blocking packages must be explicitly forbidden. >> ~ * A new src_prepare phase function is called after src_unpack. >> >> ~ * The old src_compile phase function is split into separate >> ~ src_configure and src_compile fuctions. > > All I do see is more complexity, but no real benefit. My impression is that most people tend to see these as useful extensions despite the slight increases in complexity. > > Carsten [1] http://archives.gentoo.org/gentoo-dev/msg_2551bea5c002093d5bacc26723208d93.xml - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjNR5sACgkQ/ejvha5XGaPR0gCgkiG7H4HZ4ASh/SyLboFGTCix 50EAmwU6WWU3gx5GV+EU1NqRmY+s4fDb =rbQz -----END PGP SIGNATURE-----
