On Thu, 07 Sep 2006 16:42:11 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote:
> Carsten Lohrke wrote: > > One question remains: Is it needed/correct that Portage doesn't > > take blockers for architecture breakages into account? Such a > > line/prefix is easily changed and when someone - whatever the bad > > reason is - uses cvs commit, a real tree breakage is the cause. > > The behaviour is correct. The depstring in question was > "!<app-text/hunspell-1.0", which means that you can't have > <hunspell-1.0 and kdelibs installed on a system at the same time. > Reason for this could e.g. be file collisions that got fixed in > hunspell-1.0. > > If the depstring was "!<app-text/hunspell-1.0 app-text/hunspell", > (same as ">=app-text/hunspell-1.0", just retarded) repoman would > complain loudly. 1,$ s/hunspell/hspell/g :) To follow up in the use of a blocker - obviously blocking something like kdelibs, a core part of a major package suite, against a utility like hspell is less than ideal (to put it politely). This was not the case before - kdelibs and hspell could happily be installed on the same system, just kdelibs wouldn't make use of hspell. Adding the blocker unnecessarily restricts the system, and was the wrong thing to do. One point that illustrates this clearly, is that if kdelibs is blocked by hspell, a corollary is that hspell should block kdelibs. However since hspell wasn't blocking kdelibs, you would fail to install kdelibs until hspell was unmerged. Unmerging hspell would allow kdelibs to merge, then you could happily install hspell again and end up with a confused dep tree. Also, to my understanding, having configure automagically build support for hspell if it's available on the system is not the way we're supposed to handle such dependencies. -- Kevin F. Quinn
signature.asc
Description: PGP signature
