Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers

[Kevin F. Quinn]

On Thu, 07 Sep 2006 16:42:11 +0200
Simon Stelling <blubb@g.o> 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