[gentoo-pms] Clarify wording on self-blockers

[gentoo-pms] Clarify wording on self-blockers

[Ulrich Mueller]

It's not quite clear what a "block on an ebuild" is, so let's clarify
the wording such that it agrees with portage behaviour.

Portage ignores self-blockers both in DEPEND and RDEPEND.

Ulrich


From 4161e17efacbcb58b6a1de9484cfe683c1e74e65 Mon Sep 17 00:00:00 2001
From: Ulrich Mueller <ulm@gentoo.org>
Date: Tue, 26 Apr 2011 19:10:51 +0200
Subject: [PATCH] Clarify wording on self-blockers.

---
 dependencies.tex |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/dependencies.tex b/dependencies.tex
index 362f6cc..6ea179c 100644
--- a/dependencies.tex
+++ b/dependencies.tex
@@ -187,7 +187,7 @@ following exceptions:
 
 \begin{compactitem}
 \item Blocks on a package provided exclusively by the ebuild do not count. \label{provided-blocks}
-\item Blocks on the ebuild itself do not count.
+\item Blocks on the package version of the ebuild itself do not count.
 \end{compactitem}
 
 \featurelabel{bang-strength} There are two strengths of block: weak and strong. A weak block may be
-- 
1.7.5.rc1

Re: [gentoo-pms] Clarify wording on self-blockers

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 999 bytes --]

On Tue, 26 Apr 2011 19:28:39 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> It's not quite clear what a "block on an ebuild" is, so let's clarify
> the wording such that it agrees with portage behaviour.
> 
> Portage ignores self-blockers both in DEPEND and RDEPEND.

Even strong blockers?

Also, what happens for packages that can't be rebuilt once they're
installed (e.g. because they screw up and use stuff on / if it's there)?
We've got this weird situation where DEPEND=!!self would prevent you
from upgrading or downgrading, but wouldn't stop you from rebuilding
the exact same version. That doesn't seem right.

It seems weird that we're mandating that a package manager should just
outright ignore bits of dependency variables. Maybe it would be better
to mark it as undefined as to whether or not the package manager
honours such a block (and tell people not to do it), and then for the
next EAPI figure out the logical meaning and specify that?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Ulrich Mueller]

>>>>> On Tue, 26 Apr 2011, Ciaran McCreesh wrote:

>> Portage ignores self-blockers both in DEPEND and RDEPEND.

> Even strong blockers?

No, strongs blockers are honoured in this case. (Which is fine, since
the spec says "A strong block must not be ignored.")

Updated patch (I've added the word "weak") is included below.

> Also, what happens for packages that can't be rebuilt once they're
> installed (e.g. because they screw up and use stuff on / if it's
> there)?

Such packages should be fixed. But if someone really needs a DEPEND
blocker on the ebuild's version itself, he can use EAPI 2 or later and
a strong blocker.

> We've got this weird situation where DEPEND=!!self would prevent you
> from upgrading or downgrading, but wouldn't stop you from rebuilding
> the exact same version. That doesn't seem right.

> It seems weird that we're mandating that a package manager should
> just outright ignore bits of dependency variables. Maybe it would be
> better to mark it as undefined as to whether or not the package
> manager honours such a block (and tell people not to do it), and
> then for the next EAPI figure out the logical meaning and specify
> that?

I don't like adding such "undefined" bits in cases where portage
behaviour is well-defined.

Ulrich


From 5935aa87d46a97a72c8c032728f50a6ecbdf864d Mon Sep 17 00:00:00 2001
From: Ulrich Mueller <ulm@gentoo.org>
Date: Tue, 26 Apr 2011 19:10:51 +0200
Subject: [PATCH] Clarify wording on self-blockers.

---
 dependencies.tex |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/dependencies.tex b/dependencies.tex
index 362f6cc..f6318d8 100644
--- a/dependencies.tex
+++ b/dependencies.tex
@@ -187,7 +187,7 @@ following exceptions:
 
 \begin{compactitem}
 \item Blocks on a package provided exclusively by the ebuild do not count. \label{provided-blocks}
-\item Blocks on the ebuild itself do not count.
+\item Weak blocks on the package version of the ebuild itself do not count.
 \end{compactitem}
 
 \featurelabel{bang-strength} There are two strengths of block: weak and strong. A weak block may be
-- 
1.7.5.rc1

Re: [gentoo-pms] Clarify wording on self-blockers

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Tue, 26 Apr 2011 20:19:17 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> I don't like adding such "undefined" bits in cases where portage
> behaviour is well-defined.

It's not well-defined, though. Different Portage versions have done
very different things for it. Remember that strong vs weak blockers are
a recent invention, and that in the old days Portage treated all
blockers as being a bit like what strong blockers are now.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 858 bytes --]

On Tuesday 26 of April 2011 20:25:26 Ciaran McCreesh wrote:
> On Tue, 26 Apr 2011 20:19:17 +0200
> 
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > I don't like adding such "undefined" bits in cases where portage
> > behaviour is well-defined.
> 
> It's not well-defined, though. Different Portage versions have done
> very different things for it. Remember that strong vs weak blockers are
> a recent invention, and that in the old days Portage treated all
> blockers as being a bit like what strong blockers are now.

AFAIK strong blockers were introduced with EAPI-2 which was introduced around 
two and a half year ago which is considered ancient times already and not 
recent like you would suggest.

I'd say using "in some ancient portage" argument all over again to reinforce 
particular point of view is not valid.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

On Wed, 27 Apr 2011 19:40:47 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:
> I'd say using "in some ancient portage" argument all over again to
> reinforce particular point of view is not valid.

Uh, no, that's the entire point of EAPIs.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 2194 bytes --]

On Wednesday 27 of April 2011 19:46:21 Ciaran McCreesh wrote:
> On Wed, 27 Apr 2011 19:40:47 +0200

> Maciej Mrozowski <reavertm@gmail.com> wrote:
> > I'd say using "in some ancient portage" argument all over again to
> > reinforce particular point of view is not valid.
> 
> Uh, no, that's the entire point of EAPIs.

This is a common misconception.

The entire and only point of EAPI is to provide ebuild API - for ebuild 
developers and for package manager developers.

From user point of view - user is required to update package manager (it's the 
case with portage anyway) to the latest supported version and package manager 
itself (along with package tree) needs to support such migration path (of 
course within reasonable timespan - there is catch whether pre-EAPI-2 support 
is reasonable, python eclass problem).

From ebuild developer point of view - EAPI specification should provide all 
knowledge required to create ebuilds along with detailed and unambiguous 
description of what to expect from package manager that is compliant with said 
EAPI. Old package managers and their expected behaviour is irrelevant as soon 
as migration path to recent version exists for them. That being said this 
argument blocking the update of specification because of the hypothetical 
existence of unsupported package manager instances (like ancient 
portage/paludis/pkgcore versions) is invalid.

From package manager developer point of view - EAPI specification should 
provide all knowledge required to build own package manager compliant with 
said EAPI, describing its *intended* (and of course being in effect, not just 
intended) behaviour in detailed and unambiguous way. And here again, old 
package managers and their provided behaviour is irrelevant as soon as 
migration path exists for them.

Since intended behaviour for normal vs strong blocks is like Ulrich specified, 
and migration path to the most recent from first portage supporting EAPI-2 
exists - argument to block specification update is invalid.

EAPI specification is not "what used to be", it's "what is and what can be 
relied upon", it's that simple.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

On Wed, 27 Apr 2011 21:09:58 +0200
Maciej Mrozowski <reavertm@gmail.com> wrote:
> > Uh, no, that's the entire point of EAPIs.
> 
> This is a common misconception.

Uh, no. You are completely and horribly wrong.

EAPIs were introduced to avoid the problems that we used to have where
different versions of Portage did different things with the same input
(including, but not limited to, difficulties in adding new features).

> From ebuild developer point of view - EAPI specification should
> provide all knowledge required to create ebuilds along with detailed
> and unambiguous description of what to expect from package manager
> that is compliant with said EAPI. 

Oh heck no. That really isn't the point at all.

From an ebuild developer's point of view, PMS describes (or at least
tries to describe -- the case under discussion here is one where PMS
probably needs fixing) what can and cannot be relied upon from the
package manager. The EAPI feature is used to restrict your ebuild's
availability to *all* package manager versions supporting a particular
set of features. Not "the most recent Portage version". *ALL* versions
of Portage that claim support for the EAPI in question.

> Old package managers and their expected behaviour is irrelevant as
> soon as migration path to recent version exists for them. 

Again, you are deeply confused. It is required that an upgrade path for
old package managers is kept around for as long as possible by not
using newer EAPIs for certain key system packages. This is entirely
different to what you're saying -- it means that certain packages
should be kept at low EAPIs for as long as possible, not that EAPIs are
whatever the latest Portage version does.

> Since intended behaviour for normal vs strong blocks is like Ulrich
> specified, and migration path to the most recent from first portage
> supporting EAPI-2 exists - argument to block specification update is
> invalid.

That doesn't follow at all. What happens if someone has an old Portage
installed and the migration path includes things that rely upon a
changed behaviour? Since you're trying to retroactively define a
particular behaviour for all EAPIs that doesn't match what some old
Portage versions do, your upgrade path is screwed.

This sort of thing really should be in the developer quiz. It's too
basic and fundamental for people to be getting wrong.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Maciej Mrozowski]

[-- Attachment #1: Type: text/plain, Size: 5435 bytes --]

On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote:

> > > Uh, no, that's the entire point of EAPIs.
> > 
> > This is a common misconception.
> 
> Uh, no. You are completely and horribly wrong.

> EAPIs were introduced to avoid the problems that we used to have where
> different versions of Portage did different things with the same input
> (including, but not limited to, difficulties in adding new features).
> 
> > From ebuild developer point of view - EAPI specification should
> > provide all knowledge required to create ebuilds along with detailed
> > and unambiguous description of what to expect from package manager
> > that is compliant with said EAPI.
> 
> Oh heck no. That really isn't the point at all.

But it is. Discussion about blocks is precisely about what is expected package 
manager behaviour for self-mutual blocks (in EAPI>=2) in such case. And what 
you propose is 'behaviour is undefined for self-mutual blocks' - if so, why 
are they permitted by specification and not banned instead? The way you 
understand the word 'specification' doesn't really allow any specs bugfixes 
since they would "magically" invalidate any existing implementations, unless 
there is just one (and actually there *is* just one *supported*) so that 
specification could be kept in sync with it.

How does Paludis handle normal and/or strong self-blocks? And how PkgCore 
does? Is blocks situation ever going to be clarified/improved in package 
manager level? What with other PMS issues?
No, specification will be out of sync because every single random package 
manager developer will implement it his/her way, and then claim said package 
manager is compliant and specification cannot be fixed since it changes 
behaviour. No, it doesn't change behaviour of any implementation - it will 
make it possible to determine that some particular implementation is not 
compliant. It is to mean that some ancient portage is not compliant with 
hopefully-soon-to-be-updated specification? Yes indeed, that's the result of 
updating *specification*. Maybe also the point.

> From an ebuild developer's point of view, PMS describes (or at least
> tries to describe -- the case under discussion here is one where PMS
> probably needs fixing) what can and cannot be relied upon from the
> package manager. The EAPI feature is used to restrict your ebuild's
> availability to *all* package manager versions supporting a particular
> set of features. Not "the most recent Portage version". *ALL* versions
> of Portage that claim support for the EAPI in question.

(I'm tempted to quote some random definition for fun)

Ebuild developer looks at PMS through a view called EAPI so ebuild developer 
is interested in package manager behaviour in said EAPI that's why I said EAPI 
not PMS.
And Portage is frankly the only supported package manager in Gentoo.

If one wanted PMS to document behaviour of all known portage/paludis/pkgcore 
versions in PMS, one would need to be much more specific: what behaviour 
applies to what versions of particular package manager so that one really 
knows what can and what cannot be relied upon.

But I suppose it's not the point.

I thought PMS is specification and not a documentation - hence it should 
specify (to document would be poor choice of words.. ) intended, widely agreed 
behaviour and *defined* behaviour so that ebuild developer knows how to write 
ebuilds that work against PM *compliant* with specification and package 
manager developer knows how to write *compliant* PM. And because there are 
many places where PMS is too vague, it misses those goals.

> > Old package managers and their expected behaviour is irrelevant as
> > soon as migration path to recent version exists for them.
> 
> Again, you are deeply confused. It is required that an upgrade path for
> old package managers is kept around for as long as possible by not
> using newer EAPIs for certain key system packages. This is entirely
> different to what you're saying -- it means that certain packages
> should be kept at low EAPIs for as long as possible, not that EAPIs are
> whatever the latest Portage version does.

No, you're making it up here.

> > Since intended behaviour for normal vs strong blocks is like Ulrich
> > specified, and migration path to the most recent from first portage
> > supporting EAPI-2 exists - argument to block specification update is
> > invalid.
> 
> That doesn't follow at all. What happens if someone has an old Portage
> installed and the migration path includes things that rely upon a
> changed behaviour?

It wouldn't be a migration path, would it?

> Since you're trying to retroactively define a
> particular behaviour for all EAPIs that doesn't match what some old
> Portage versions do, your upgrade path is screwed.

No, I'm supporting *defining* behaviour as it's intended so that package 
managers are able to know whether they are correct. You're making all of them 
correct by explicitly allowing them to do anything here and there - it's not 
helping.

> This sort of thing really should be in the developer quiz. It's too
> basic and fundamental for people to be getting wrong.

Comprehensive reading is that sort of thing as well.

Ulrich: maybe we should consider renaming PMS to PMD? :P

(btw, I'm subscribed to this list)

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Brian Harring]

On Wed, Apr 27, 2011 at 11:34:00PM +0200, Maciej Mrozowski wrote:
> On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote:
> 
> > > > Uh, no, that's the entire point of EAPIs.
> > > 
> > > This is a common misconception.
> > 
> > Uh, no. You are completely and horribly wrong.
> 
> > EAPIs were introduced to avoid the problems that we used to have where
> > different versions of Portage did different things with the same input
> > (including, but not limited to, difficulties in adding new features).

To be clear, Ciaran is very much correct here- I added EAPI in to 
fix ongoing shit like this where overlays/old ebuilds in the 
tree would be broken via the latest/greatest insanity portage leveled, 
and to allow new ebuild functionality to roll out quickly instead of 
having to sit for at least a year.

This is *exactly* the point of EAPI- it's format versioning for 
compatibility.  As such once a version is considered "released" or 
"stable", it's basically immutable.

EAPI was explicitly designed to allow a portage from 2 years back to 
be able to function w/ ebuilds written to that EAPI- assuming the 
version of portage in use was compliant w/ the EAPI2 (from 2 years 
back), it should still function w/ ebuilds written in current times 
that are EAPI2.

Not saying it was done *perfectly*, but this is a large part of it's 
intent.


> > > From ebuild developer point of view - EAPI specification should
> > > provide all knowledge required to create ebuilds along with detailed
> > > and unambiguous description of what to expect from package manager
> > > that is compliant with said EAPI.
> > 
> > Oh heck no. That really isn't the point at all.
> 
> But it is. Discussion about blocks is precisely about what is expected package 
> manager behaviour for self-mutual blocks (in EAPI>=2) in such case. And what 
> you propose is 'behaviour is undefined for self-mutual blocks' - if so, why 
> are they permitted by specification and not banned instead? The way you 
> understand the word 'specification' doesn't really allow any specs bugfixes 
> since they would "magically" invalidate any existing implementations, unless 
> there is just one (and actually there *is* just one *supported*) so that 
> specification could be kept in sync with it.

Ciaran's coming at this from the academic definition of 
"specification".  In a perfect world, it's correct- once a spec is 
stabled, it's immutable sans clarifying wording/intent, and even that 
involves occasionally converting bad parts of the spec to unspecified 
(or unspecified if a large PM screwed up their implementation badly 
enough you can't rely on that assertion any longer).

Pragmatism is such that bugfixes/tweaks do get pushed in where 
required, and where it doesn't fuck us hard to do so.

As for *why* they're allowed in the first place, it's because the spec 
is incomplete- it has a large number of assertions, but covering all 
of it is fairly hard (and questionable in usefulness for certain 
spots)- I generally hate 'unspecified', but the primary usefullness is 
to make clear that proceeding behaviour could vary across PMs- 
specifically it should be used when 

> I thought PMS is specification and not a documentation - hence it should 
> specify (to document would be poor choice of words.. ) intended, widely agreed 
> behaviour and *defined* behaviour so that ebuild developer knows how to write 
> ebuilds that work against PM *compliant* with specification and package 
> manager developer knows how to write *compliant* PM. And because there are 
> many places where PMS is too vague, it misses those goals.

Asserting all behaviour is actually fairly hard.  Patches welcome for 
that intent, but additions to the spec have to be written to avoid 
breaking previous assertions in the spec- as said, a portage that was 
EAPI2 compliant 2 years back needs to work with ebuilds that EAPI2 
from today.

It sucks, but this is /proper/ versioning.  It's a hard problem.


> > > Old package managers and their expected behaviour is irrelevant as
> > > soon as migration path to recent version exists for them.
> > 
> > Again, you are deeply confused. It is required that an upgrade path for
> > old package managers is kept around for as long as possible by not
> > using newer EAPIs for certain key system packages. This is entirely
> > different to what you're saying -- it means that certain packages
> > should be kept at low EAPIs for as long as possible, not that EAPIs are
> > whatever the latest Portage version does.
> 
> No, you're making it up here.

This is actually required.  Abided by?  Not as well as it should 
(python has been fucking that one up hard), but take a look at glibc's 
eapi, gcc, binutils... etc.

This is *exactly* what we intended when EAPI was added 5.5 years ago 
(and was the intent for the year or so before a patch got pushed in).


> > > Since intended behaviour for normal vs strong blocks is like Ulrich
> > > specified, and migration path to the most recent from first portage
> > > supporting EAPI-2 exists - argument to block specification update is
> > > invalid.
> > 
> > That doesn't follow at all. What happens if someone has an old Portage
> > installed and the migration path includes things that rely upon a
> > changed behaviour?
> 
> It wouldn't be a migration path, would it?

You're proving his point.


> > Since you're trying to retroactively define a
> > particular behaviour for all EAPIs that doesn't match what some old
> > Portage versions do, your upgrade path is screwed.
> 
> No, I'm supporting *defining* behaviour as it's intended so that package 
> managers are able to know whether they are correct. You're making all of them 
> correct by explicitly allowing them to do anything here and there - it's not 
> helping.

What you're not getting is proper format support.  Yes, there are 
areas in eapi0, 1, 2, etc, that I'd *love* to go back and make a 
clearer definition on- the problem is ensuring that all versions of 
portage/pkgcore/paludis that supported those EAPI's are still 
compliant.  If that can be assured, then, within limits, we can 
redefine previous EAPIs- because effectively we're not actually 
defining any *new* behaviour, just clarifying old behaviour that 
happily matches what we want now.

If those things hold, we can't do it, and that's a fact of defining 
versioned formats.


> Ulrich: maybe we should consider renaming PMS to PMD? :P

It certainly would be nice being able to avoid stating "active in 
gentoo's PMS process" for folks resumes, I must say (which is where a 
lot of the juvenile humour derives from I suspect).

So... rather than continuing to argue about what EAPI was intended 
for, lets switch back to whether or not we can clarify the rules for 
self blockers in existing EAPIs, and what we'd like it to be for 
>=EAPI5..

~harring

Re: [gentoo-pms] Clarify wording on self-blockers

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 10187 bytes --]

On Monday 02 of May 2011 03:41:43 Brian Harring wrote:
> On Wed, Apr 27, 2011 at 11:34:00PM +0200, Maciej Mrozowski wrote:
> > On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote:
> > > > > Uh, no, that's the entire point of EAPIs.
> > > > 
> > > > This is a common misconception.
> > > 
> > > Uh, no. You are completely and horribly wrong.
> > > 
> > > EAPIs were introduced to avoid the problems that we used to have where
> > > different versions of Portage did different things with the same input
> > > (including, but not limited to, difficulties in adding new features).
> 
> To be clear, Ciaran is very much correct here- I added EAPI in to
> fix ongoing shit like this where overlays/old ebuilds in the
> tree would be broken via the latest/greatest insanity portage leveled,
> and to allow new ebuild functionality to roll out quickly instead of
> having to sit for at least a year.
> 
> This is *exactly* the point of EAPI- it's format versioning for
> compatibility.  As such once a version is considered "released" or
> "stable", it's basically immutable.
> 
> EAPI was explicitly designed to allow a portage from 2 years back to
> be able to function w/ ebuilds written to that EAPI- assuming the
> version of portage in use was compliant w/ the EAPI2 (from 2 years
> back), it should still function w/ ebuilds written in current times
> that are EAPI2.

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. 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) 

> Not saying it was done *perfectly*, but this is a large part of it's
> intent.
> 
> > > > From ebuild developer point of view - EAPI specification should
> > > > provide all knowledge required to create ebuilds along with detailed
> > > > and unambiguous description of what to expect from package manager
> > > > that is compliant with said EAPI.
> > > 
> > > Oh heck no. That really isn't the point at all.
> > 
> > But it is. Discussion about blocks is precisely about what is expected
> > package manager behaviour for self-mutual blocks (in EAPI>=2) in such
> > case. And what you propose is 'behaviour is undefined for self-mutual
> > blocks' - if so, why are they permitted by specification and not banned
> > instead? The way you understand the word 'specification' doesn't really
> > allow any specs bugfixes since they would "magically" invalidate any
> > existing implementations, unless there is just one (and actually there
> > *is* just one *supported*) so that specification could be kept in sync
> > with it.
> 
> Ciaran's coming at this from the academic definition of
> "specification".  In a perfect world, it's correct- once a spec is
> stabled, it's immutable sans clarifying wording/intent, and even that
> involves occasionally converting bad parts of the spec to unspecified
> (or unspecified if a large PM screwed up their implementation badly
> enough you can't rely on that assertion any longer).
> 
> Pragmatism is such that bugfixes/tweaks do get pushed in where
> required, and where it doesn't fuck us hard to do so.
> 
> As for *why* they're allowed in the first place, it's because the spec
> is incomplete- it has a large number of assertions, but covering all
> of it is fairly hard (and questionable in usefulness for certain
> spots)- I generally hate 'unspecified', but the primary usefullness is
> to make clear that proceeding behaviour could vary across PMs-
> specifically it should be used when
> 
> > I thought PMS is specification and not a documentation - hence it should
> > specify (to document would be poor choice of words.. ) intended, widely
> > agreed behaviour and *defined* behaviour so that ebuild developer knows
> > how to write ebuilds that work against PM *compliant* with specification
> > and package manager developer knows how to write *compliant* PM. And
> > because there are many places where PMS is too vague, it misses those
> > goals.
> 
> Asserting all behaviour is actually fairly hard.  Patches welcome for
> that intent, but additions to the spec have to be written to avoid
> breaking previous assertions in the spec- as said, a portage that was
> EAPI2 compliant 2 years back needs to work with ebuilds that EAPI2
> from today.
> 
> It sucks, but this is /proper/ versioning.  It's a hard problem.
> 
> > > > Old package managers and their expected behaviour is irrelevant as
> > > > soon as migration path to recent version exists for them.
> > > 
> > > Again, you are deeply confused. It is required that an upgrade path for
> > > old package managers is kept around for as long as possible by not
> > > using newer EAPIs for certain key system packages. This is entirely
> > > different to what you're saying -- it means that certain packages
> > > should be kept at low EAPIs for as long as possible, not that EAPIs are
> > > whatever the latest Portage version does.
> > 
> > No, you're making it up here.
> 
> This is actually required.  Abided by?  Not as well as it should
> (python has been fucking that one up hard), but take a look at glibc's
> eapi, gcc, binutils... etc.
> 
> This is *exactly* what we intended when EAPI was added 5.5 years ago
> (and was the intent for the year or so before a patch got pushed in).
> 
> > > > Since intended behaviour for normal vs strong blocks is like Ulrich
> > > > specified, and migration path to the most recent from first portage
> > > > supporting EAPI-2 exists - argument to block specification update is
> > > > invalid.
> > > 
> > > That doesn't follow at all. What happens if someone has an old Portage
> > > installed and the migration path includes things that rely upon a
> > > changed behaviour?
> > 
> > It wouldn't be a migration path, would it?
> 
> You're proving his point.

Not necessarily.
Migration path to the version of <insert your favourite package manager here> 
that is compliant with updated specification doesn't have to involve relying 
on changed behaviour (changed at this point only in specification since old 
package manager is being used to update to the newer one after all).

And why do I argue on effectively dropping support for older versions and to 
keep specification in sync with the latest version as much as possible (across 
package managers)?

Maintenance cost.
Every new EAPI requires added codepaths and it adds potential complexity if 
for instance dependency resolver behaviour is altered. If every little 
specification cleanup was conducted by bumping EAPI, it would lead to 
unmaintainable code (I know people like spaghetti though).
Well, just look at portage - only few are brave enough to touch it and even 
fewer know how it really works.
And since Gentoo lives in $0 budget working environment, resource constrains 
(time * manpower) should be considered. Since there's no budget for rewrite, 
we should simplify instead.

> > > Since you're trying to retroactively define a
> > > particular behaviour for all EAPIs that doesn't match what some old
> > > Portage versions do, your upgrade path is screwed.
> > 
> > No, I'm supporting *defining* behaviour as it's intended so that package
> > managers are able to know whether they are correct. You're making all of
> > them correct by explicitly allowing them to do anything here and there -
> > it's not helping.
> 
> What you're not getting is proper format support.  Yes, there are
> areas in eapi0, 1, 2, etc, that I'd *love* to go back and make a
> clearer definition on- the problem is ensuring that all versions of
> portage/pkgcore/paludis that supported those EAPI's are still
> compliant.  If that can be assured, then, within limits, we can
> redefine previous EAPIs- because effectively we're not actually
> defining any *new* behaviour, just clarifying old behaviour that
> happily matches what we want now.
> 
> If those things hold, we can't do it, and that's a fact of defining
> versioned formats.
> 
> > Ulrich: maybe we should consider renaming PMS to PMD? :P
> 
> It certainly would be nice being able to avoid stating "active in
> gentoo's PMS process" for folks resumes, I must say (which is where a
> lot of the juvenile humour derives from I suspect).

Missed. I never meant to state I was active in Gentoo PMS process, "we" comes 
from wearing certain hat if it wasn't clear enough (that being said I just 
prefer not to use @gentoo.org in mailing lists just to observe how people 
react to "third-parties").

> So... rather than continuing to argue about what EAPI was intended
> for, lets switch back to whether or not we can clarify the rules for
> self blockers in existing EAPIs, and what we'd like it to be for
> >=EAPI5..

Yes.
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).

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, to my knowledge 
in all Portage versions supporting EAPI-2 this behaviour is consistent, well-
defined and as such could be documented as in effect for >=EAPI-2 (with 
possible altering in EAPI-5 - for instance non-strong self-blocks forbidden or 
sth)

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Clarify wording on self-blockers

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]

On Mon, 2 May 2011 14:34:11 +0200
Maciej Mrozowski <reavertm@gmail.com> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]