Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-pms
Navigation:
Lists: gentoo-pms: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-pms@g.o
From: Ciaran McCreesh <ciaran.mccreesh@...>
Subject: Re: Clarify wording on self-blockers
Date: Mon, 2 May 2011 14:10:57 +0100
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.

-- 
Ciaran McCreesh
Attachment:
signature.asc (PGP signature)
References:
Clarify wording on self-blockers
-- Ulrich Mueller
Re: Clarify wording on self-blockers
-- Maciej Mrozowski
Re: Clarify wording on self-blockers
-- Brian Harring
Re: Clarify wording on self-blockers
-- Maciej Mrozowski
Navigation:
Lists: gentoo-pms: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Clarify wording on self-blockers
Next by thread:
The PMS test suite GSoC project
Previous by date:
Re: Clarify wording on self-blockers
Next by date:
The PMS test suite GSoC project


Updated Jul 18, 2012

Summary: Archive of the gentoo-pms mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.