On Mon, 2 May 2011 14:34:11 +0200
Maciej Mrozowski <reavertm@...> wrote:
> And wrt blocks it would still work. It's not like clarifying
> self-mutual blocks semantics would magically alter behaviour with
> regards to how the package is merged. It may only have consequences
> on package set level, not ebuild level.
You can't split the two concepts up. Whether or not a package builds is
affected by what is or isn't installed.
> But then again, IIRC Paludis still doesn't perform auto- unmerging of
> not referenced soft-blocked packages and it's being extensively used
> in gentoo-x86 tree and I see nobody screaming... (this may have
> changed however, my point is invalid if that's the case)
Paludis won't uninstall things without explicit permission. It will,
however, tell the user that something is blocked, and give the user the
option of saying "yes, uninstall that". This is deliberate, to avoid
the situations we've had with Portage uninstalling bash.
Also note that Paludis treats pre-EAPI 2 ! blocks as being strong, not
weak. Again, deliberate, because that's what authors of pre-EAPI 2
ebuilds originally intended.
> The problem is that person most interested in participating in such
> discussion, the one solely responsible for reference and supported
> package manager implementation (for Gentoo) is Zac, but he's not
> interested in (or doesn't have time for) bickering with Ciaran (who
> apparently does have time) and I don't blame him at all frankly (I
> don't blame Ciaran either, he could just try to avoid stating his
> opinion on how broken Portage is on every single occasion he has like
> anyone even cared.. and send patches instead).
What I have time for is making sure we get this right at the
specification level. Mistakes in the specification cost a lot more in
the long term than careful consideration of consequences does in the
short term. The last time blockers were changed without careful
thought, lots of things broke horribly, and we're still hitting obscure
breakages years later.
As for sending patches, you said it yourself:
> Well, just look at portage - only few are brave enough to
> touch it and even fewer know how it really works.
So I've done something better: I've made an alternative that doesn't
have those problems.
> Anyway Ciaran diverged discussion to what's the purpose of EAPI and
> what's not. Not sure what's the time line for "in the old days
> Portage treated all blockers as being a bit like what strong blockers
> are now" is
It's after EAPI 0, thus, we control changes to it using EAPIs. Simple!
Again, getting this right *matters*. Regarding the original bug that
brought our attention to this, I believe the first part of the problem
there is that some cron packages are using pre-2 EAPIs, which means
their ! blockers are treated by recent Portage versions as weak (and
old Portage versions as strong) but by Paludis as strong.