[gentoo-pms] Mismatch between tree and PMS

[gentoo-pms] Mismatch between tree and PMS

[Patrick Lauer]

For a long time (about a year, as far as I can tell) PMS has failed to 
document the bash version needed properly. Relying on PMS will not yield a 
working package manager in this case as in-tree ebuilds and eclasses have 
moved on for quite some time. This simple one-character fix should make PMS 
respect reality for that part again:


diff --git a/ebuild-format.tex b/ebuild-format.tex
index d6c8270..d814cfa 100644
--- a/ebuild-format.tex
+++ b/ebuild-format.tex
@@ -2,7 +2,7 @@
 \label{sec:ebuild-format}

 The ebuild file format is in its basic form a subset of the format of a bash 
script. The interpreter
-is assumed to be GNU bash, version 3.0 or later. The file encoding must be 
UTF-8 with Unix-style
+is assumed to be GNU bash, version 3.2 or later. The file encoding must be 
UTF-8 with Unix-style
 newlines. When sourced, the
 ebuild must define certain variables and functions (see 
sections~\ref{sec:ebuild-vars} and
 \ref{sec:ebuild-functions} for specific information), and must not call any 
external programs, write

Re: [gentoo-pms] Mismatch between tree and PMS

[Ciaran McCreesh]

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

On Fri, 18 Sep 2009 16:01:20 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> For a long time (about a year, as far as I can tell) PMS has failed
> to document the bash version needed properly. Relying on PMS will not
> yield a working package manager in this case as in-tree ebuilds and
> eclasses have moved on for quite some time. This simple one-character
> fix should make PMS respect reality for that part again:

Sorry, we can't change this for three reasons.

First, it's a retroactive change to an older EAPI. We don't have the
authority to do that.

Second, the bash version decision was made by the Council, not us.

Third, changing it breaks sourcing done by older, Council-approved EAPI
compliant package managers. We can't do this, and we can't even do it
on an EAPI bump.

The solution here's to fix the tree.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] Mismatch between tree and PMS

[Patrick Lauer]

On Friday 18 September 2009 16:08:29 Ciaran McCreesh wrote:
> On Fri, 18 Sep 2009 16:01:20 +0200
> 
> Patrick Lauer <patrick@gentoo.org> wrote:
> > For a long time (about a year, as far as I can tell) PMS has failed
> > to document the bash version needed properly. Relying on PMS will not
> > yield a working package manager in this case as in-tree ebuilds and
> > eclasses have moved on for quite some time. This simple one-character
> > fix should make PMS respect reality for that part again:
[ fix PMS to demand bash 3.2 instead of 3.0 ]

> Sorry, we can't change this for three reasons.
We have to change it for one reason: Specs need to match reality
 
> First, it's a retroactive change to an older EAPI. We don't have the
> authority to do that.
Who does?
 
> Second, the bash version decision was made by the Council, not us.
The dev community decided to improve upon that decision. Council has not tried 
to stop it. After about a year and moderate use (I count over 150 uses in 
eclasses alone) there's no way to migrate back. So the "correct" thing to do 
is for council to vote on it at the next meeting I guess ...

> Third, changing it breaks sourcing done by older, Council-approved EAPI
> compliant package managers. We can't do this, and we can't even do it
> on an EAPI bump.
Wargharbl.
Not changing it breaks sourcing on council-approved trees. We can do it, and 
we have to do it if PMS is supposed to have any relevance at all.


> The solution here's to fix the tree.
That might have been a possible solution a year ago. Too late now.  
(Also, if you want to play semantic games ...
"The interpreter is assumed to be GNU bash, version 3.0 or later."
One could interpret it that any version [and any feature provided by later 
versions] is acceptable, which would allow bash4 features in ebuilds now as 
bash4 is stable. That would definitely not be what you'd expect.)

wkr,

Patrick

Re: [gentoo-pms] Mismatch between tree and PMS

[Ciaran McCreesh]

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

On Fri, 18 Sep 2009 16:28:44 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> [ fix PMS to demand bash 3.2 instead of 3.0 ]
> 
> > Sorry, we can't change this for three reasons.
> We have to change it for one reason: Specs need to match reality

PMS isn't the place to push through changes.

> > First, it's a retroactive change to an older EAPI. We don't have the
> > authority to do that.
> Who does?

The Council. Probably no-one else. We've always gone to the gentoo-dev
list for consultations (explaining the full impact of the issue), and
then asked for Council approval for retroactive changes to existing
EAPIs. I think a lot of people would be very uncomfortable with the
idea of the PMS project having the authority to make that kind of
decision on its own.

> > Third, changing it breaks sourcing done by older, Council-approved
> > EAPI compliant package managers. We can't do this, and we can't
> > even do it on an EAPI bump.
> Wargharbl.
> Not changing it breaks sourcing on council-approved trees. We can do
> it, and we have to do it if PMS is supposed to have any relevance at
> all.

No, the change can't be made without breaking the upgrade path. Users
who have an old EAPI 0 system with bash 3.0 installed need to be able
to upgrade it, and they can't do that if they can't source ebuilds. The
impact of the change you're suggesting has to be considered, and it's
not a simple decision to make.

> > The solution here's to fix the tree.
> That might have been a possible solution a year ago. Too late now.  

Possibly, possibly not. It depends upon whether the Council considers
the upgrade path to be important. Users do frequently complain when the
upgrade path gets broken, so it's not a simple decision to make.

> (Also, if you want to play semantic games ...
> "The interpreter is assumed to be GNU bash, version 3.0 or later."
> One could interpret it that any version [and any feature provided by
> later versions] is acceptable, which would allow bash4 features in
> ebuilds now as bash4 is stable. That would definitely not be what
> you'd expect.)

No, that's not what that means. It means ebuilds may assume that it's
at least version 3.0, and so may make use of 3.0 features, but they may
not make any other assumptions about versions (including assuming that
things that work in bash 3 but not bash 4 are legal).

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] Mismatch between tree and PMS

[Ulrich Mueller]

>>>>> On Fri, 18 Sep 2009, Ciaran McCreesh wrote:

> No, the change can't be made without breaking the upgrade path. Users
> who have an old EAPI 0 system with bash 3.0 installed need to be able
> to upgrade it, and they can't do that if they can't source ebuilds. The
> impact of the change you're suggesting has to be considered, and it's
> not a simple decision to make.

Some relative timing of events may be interesting here:
   12 May 2007   bash-3.2_p15 stable on major architectures.
   19 Aug 2008   python-2.3.6-r6 removed, which was the last ebuild
                 of Python with EAPI 0.

So the upgrade path for EAPI 0 systems is broken anyway, for a
different reason.

And if we stay at bash-3.0, then we should probably add its ebuild to
the tree again, in order to ease compatibility testing. It was removed
half a year ago.

Ulrich

Re: [gentoo-pms] Mismatch between tree and PMS

[Ciaran McCreesh]

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

On Fri, 18 Sep 2009 17:21:43 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > On Fri, 18 Sep 2009 16:28:44 +0200
> > Patrick Lauer <patrick@gentoo.org> wrote:
> >> [ fix PMS to demand bash 3.2 instead of 3.0 ]
> 
> In short you are asking to put this item for the next council meeting.

No, I'd like to see a discussion on gentoo-dev@ started by someone who
thinks we should make the change, where that person explains fully both
sides of the decision without resorting to FUD or comments like
"warblgarbl". Once that discussion has taken place, and any new
viewpoints have been discussed, *then* I'd like to see the matter go to
the Council.

I don't think we should be asking for comments on changes until after
the developer-base at large has had a chance to discuss the issue. This
isn't a simple "there are advantages and no disadvantages" issue, which
is largely why it's been avoided until now.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] Mismatch between tree and PMS

[Andrew D Kirch]

Ciaran McCreesh wrote:
> On Fri, 18 Sep 2009 17:21:43 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>   
>> Ciaran McCreesh wrote:
>>     
>>> On Fri, 18 Sep 2009 16:28:44 +0200
>>> Patrick Lauer <patrick@gentoo.org> wrote:
>>>       
>>>> [ fix PMS to demand bash 3.2 instead of 3.0 ]
>>>>         
>> In short you are asking to put this item for the next council meeting.
>>     
>
> No, I'd like to see a discussion on gentoo-dev@ started by someone who
> thinks we should make the change, where that person explains fully both
> sides of the decision without resorting to FUD or comments like
> "warblgarbl". Once that discussion has taken place, and any new
> viewpoints have been discussed, *then* I'd like to see the matter go to
> the Council.
>
> I don't think we should be asking for comments on changes until after
> the developer-base at large has had a chance to discuss the issue. This
> isn't a simple "there are advantages and no disadvantages" issue, which
> is largely why it's been avoided until now.
>
>   
Ciaran

We agree on very little, but one thing we do agree on is the quantity of
trolling that DOES occur on -dev when these issues are brought up.  Is
there any method by which a discussion can be had on -PMS in a smaller
forum, and a proposal could thereby be brought to -dev in several weeks
agreed upon here, and subsequently submitted to the Council?  I'm hoping
this will reduce the potential for trolling.

Andrew

Re: [gentoo-pms] Mismatch between tree and PMS

[Ciaran McCreesh]

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

On Fri, 18 Sep 2009 11:32:34 -0400
Andrew D Kirch <trelane@trelane.net> wrote:
> We agree on very little, but one thing we do agree on is the quantity
> of trolling that DOES occur on -dev when these issues are brought
> up.  Is there any method by which a discussion can be had on -PMS in
> a smaller forum, and a proposal could thereby be brought to -dev in
> several weeks agreed upon here, and subsequently submitted to the
> Council?  I'm hoping this will reduce the potential for trolling.

That tends to be what happens anyway, and I strongly suspect we've
already covered all the pros and cons of the proposal on this list that
we're going to come up with (although there're probably some
interesting viewpoints on the upgrade path that can be had from a
wider audience). The wider consultation part is necessary, though, since
I doubt anyone wants things that aren't a simple "there's only one side
to this" to go from PMS to Council without them having had a good public
airing first.

There're threads that end up working fine on gentoo-dev@, and there're
threads where there's an endless supply of FUD posted to them. Things
that tend to help make threads the former rather than the latter are:

* The initial proposal, and any counter proposals, being clear and well
  defined, and not vague ideas that haven't been thought through. It's
  possible to screw things up for months just by replying "well I have
  an alternate proposal that involves frozbinating the glixnors", and
  then not telling anyone what that proposal is.

* Arguments for or against a proposal being expressed clearly and in
  technical terms, rather than "warblgarbl".

* Getting contributions only from people who understand the issue at
  hand. That one's the biggie, and I've not found any way of helping on
  that -- providing clear and detailed explanations of everything
  has only led to people not reading those explanations. Some people
  seem to be able to think that their opinions are relevant even if
  they're commenting on highly technical issues that they haven't taken
  the time to understand.

* Where multiple options are available, having several clearly separate
  proposals rather than trying to lump everything into a single
  proposal that covers every option.

The ultimate decision making process also hasn't helped. In the past
the Council has worked on a policy of "if there're any unanswered
questions, the proposal gets postponed", even if those questions are
obviously nonsense and have already been addressed twenty times
previously. This unfortunately means that the trolls can't simply be
ignored.

Having said that, all it takes is for a couple of people to jump on a
proposal they don't understand and start yelling that it will break
their favourite toy, and at best the proposal then gets derailed for
several months before sanity prevails.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] Mismatch between tree and PMS

[Andrew D Kirch]

Ciaran McCreesh wrote:
> On Fri, 18 Sep 2009 11:32:34 -0400
> Andrew D Kirch <trelane@trelane.net> wrote:
>   
>> We agree on very little, but one thing we do agree on is the quantity
>> of trolling that DOES occur on -dev when these issues are brought
>> up.  Is there any method by which a discussion can be had on -PMS in
>> a smaller forum, and a proposal could thereby be brought to -dev in
>> several weeks agreed upon here, and subsequently submitted to the
>> Council?  I'm hoping this will reduce the potential for trolling.
>>     
>
> That tends to be what happens anyway, and I strongly suspect we've
> already covered all the pros and cons of the proposal on this list that
> we're going to come up with (although there're probably some
> interesting viewpoints on the upgrade path that can be had from a
> wider audience). The wider consultation part is necessary, though, since
> I doubt anyone wants things that aren't a simple "there's only one side
> to this" to go from PMS to Council without them having had a good public
> airing first.
>   
Agreed, but I'd like to have something more formal, and perhaps
someplace less loud than -dev for this.

> There're threads that end up working fine on gentoo-dev@, and there're
> threads where there's an endless supply of FUD posted to them. Things
> that tend to help make threads the former rather than the latter are:
>
> * The initial proposal, and any counter proposals, being clear and well
>   defined, and not vague ideas that haven't been thought through. It's
>   possible to screw things up for months just by replying "well I have
>   an alternate proposal that involves frozbinating the glixnors", and
>   then not telling anyone what that proposal is.
>   
Agreed
> * Arguments for or against a proposal being expressed clearly and in
>   technical terms, rather than "warblgarbl".
>   
I just mentally filter out such things.
> * Getting contributions only from people who understand the issue at
>   hand. That one's the biggie, and I've not found any way of helping on
>   that -- providing clear and detailed explanations of everything
>   has only led to people not reading those explanations. Some people
>   seem to be able to think that their opinions are relevant even if
>   they're commenting on highly technical issues that they haven't taken
>   the time to understand.
>   
Opinions on the internet are like assholes, everyone has one, and some
smell more than others.
> * Where multiple options are available, having several clearly separate
>   proposals rather than trying to lump everything into a single
>   proposal that covers every option.
>
> The ultimate decision making process also hasn't helped. In the past
> the Council has worked on a policy of "if there're any unanswered
> questions, the proposal gets postponed", even if those questions are
> obviously nonsense and have already been addressed twenty times
> previously. This unfortunately means that the trolls can't simply be
> ignored.
>   
I don't think you'll get an argument from me on the failures of Council
leadership.
> Having said that, all it takes is for a couple of people to jump on a
> proposal they don't understand and start yelling that it will break
> their favourite toy, and at best the proposal then gets derailed for
> several months before sanity prevails.
>   
This is what I'm trying to avoid.  If we're going to propose something,
I'd rather hash it out here and then submit it to dev than to start a
-dev thread with "so I had this idea... maybe we could change EAPI-4 to
do X"

Andrew