[gentoo-dev] My wishlist for EAPI 5

[gentoo-dev] My wishlist for EAPI 5

[Richard Yao]

Here is my wishlist for EAPI 5:

Multilib (and/or multiarch) support
Automated epatch_user support
Parallel make checks
POSIX Shell compliance

Here are some explanations:

Multilib (and/or multiarch) support
	The current binaries cause a great deal of pain, particularly when a
user does not want to upgrade something. I had this problem with WINE
and glibc because I wanted to avoid the reverse memcpy() fiasco on my
systems. This situation would have been avoided entirely if the package
manager supported multilib.

Automated epatch_user support
	Users should be able to test patches without modifying their ebuilds.
This also saves developer time because we don't need to navigate the
portage tree (or an overlay), make a change and test it. We could just
dump the patch in the appropriate directory and build.

Parallel make checks
	As it stands, `make check` is so slow that few people actually run it
and QA suffers as a result. We have the ability to do parallel checks,
but we need to explicitly put `emake check` into the ebuild and use
autoconf 1.12 to get that. It would be best if this behavior were the
default, not the exception.

POSIX Shell compliance
	There has been a great deal of work done to give the user full control
of what is on his system and there is more that we can do there. In
particular, I think a lean Gentoo Linux system should be able to use
busybox sh and nothing else. That requires POSIX shell compliance.
OpenRC init scripts support this and the configure scripts support this.
The few exceptions are bugs that are addressed by the Gentoo BSD developers.
	As such, I think we should make EAPI=5 use POSIX shell by default. If
an ebuild requires bash, we can allow the ebuild to declare that (e.g.
WANT_SH=bash), but that should be the exception and not the rule.

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Wed, 20 Jun 2012 16:25:30 -0400
Richard Yao <ryao@gentoo.org> wrote:
> Multilib (and/or multiarch) support
> 	The current binaries cause a great deal of pain, particularly
> when a user does not want to upgrade something. I had this problem
> with WINE and glibc because I wanted to avoid the reverse memcpy()
> fiasco on my systems. This situation would have been avoided entirely
> if the package manager supported multilib.

This one's unlikely to happen unless someone's prepared to put in the
work.

> POSIX Shell compliance
> 	There has been a great deal of work done to give the user
> full control of what is on his system and there is more that we can
> do there. In particular, I think a lean Gentoo Linux system should be
> able to use busybox sh and nothing else. That requires POSIX shell
> compliance. OpenRC init scripts support this and the configure
> scripts support this. The few exceptions are bugs that are addressed
> by the Gentoo BSD developers. As such, I think we should make EAPI=5
> use POSIX shell by default. If an ebuild requires bash, we can allow
> the ebuild to declare that (e.g. WANT_SH=bash), but that should be
> the exception and not the rule.

So far as I know, every PM relies heavily upon bash anyway (and can't
easily be made not to), so even if developers would accept having to
rewrite all their eclasses, it still wouldn't remove the dep.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Richard Yao]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org>
> wrote:
>> Multilib (and/or multiarch) support The current binaries cause a
>> great deal of pain, particularly when a user does not want to
>> upgrade something. I had this problem with WINE and glibc because
>> I wanted to avoid the reverse memcpy() fiasco on my systems. This
>> situation would have been avoided entirely if the package manager
>> supported multilib.
> 
> This one's unlikely to happen unless someone's prepared to put in
> the work.

The multilib-portage overlay already has this working.

>> POSIX Shell compliance There has been a great deal of work done
>> to give the user full control of what is on his system and there
>> is more that we can do there. In particular, I think a lean
>> Gentoo Linux system should be able to use busybox sh and nothing
>> else. That requires POSIX shell compliance. OpenRC init scripts
>> support this and the configure scripts support this. The few
>> exceptions are bugs that are addressed by the Gentoo BSD
>> developers. As such, I think we should make EAPI=5 use POSIX
>> shell by default. If an ebuild requires bash, we can allow the
>> ebuild to declare that (e.g. WANT_SH=bash), but that should be 
>> the exception and not the rule.
> 
> So far as I know, every PM relies heavily upon bash anyway (and
> can't easily be made not to), so even if developers would accept
> having to rewrite all their eclasses, it still wouldn't remove the
> dep.
> 

Lets address POSIX compliance in the ebuilds first. Then we can deal
with the package managers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP4jeZAAoJECDuEZm+6Exkt6cP/jpDU3CQmCZlOJWHf2uLYPpg
+Ft2bN2JyMs1rquIrAd0PGtMXu8zrQC5U7Q0SAO1Vm+Ieu98aHknGMPWJYtV0PpU
X5/bFqk+LjaO/fFAo+x+IKET24hYXry9P27om/ZUgURKDbWvityQAeIKrZhT9U/r
LzPWgSu/v9wLDBVwZpIEjlMeYMD/uA868srBDK/dVjhZHFB6bzVK8h8xhI4zq/X3
UQYPXFuCgg2s7+g/2Z+pCvGVKwX/GdGXU8ZMRtEu3PF1hgBXBXb1qkaQRQoOGsEG
BRkOAp+MqI+/VClvxPFGGVfqvRZaqQhmg4VxYIELkPh4jzvfIJu/WC7CReOix574
hBhDXrPWwJ2r6Y1updNpWUg7yBQGRmAtmRd6AL4MVHG70j/6IlSrsGrQr8KrdxuP
BzQDTzN0rd5iDocO3bACluzxMSrd2wk73bvaAcWYsmIVVigVASHIcdvMthgx/ctw
zSEOp7sIvXejbONeIwhcqu6M6qvFi6i2o/82Mk68JXH0BAIZ2cC8atn+mmZd0SMz
R49Wu9GSyNCAeubuxTxUaEatGmSGGNtXEACxGpvtyo8XbvYmfNvntsxorRvnWNXt
hhIQQYQwVOsSUSCHSqKS1/lD/8EIWoMD531IRKEyhP6eMoGZBUFCrc94zoGLwmz5
VlJuFNCU9ylfbEWMayLC
=I8nt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 20 Jun 2012 16:50:33 -0400
Richard Yao <ryao@gentoo.org> wrote:
> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org>
> > wrote:
> >> Multilib (and/or multiarch) support The current binaries cause a
> >> great deal of pain, particularly when a user does not want to
> >> upgrade something. I had this problem with WINE and glibc because
> >> I wanted to avoid the reverse memcpy() fiasco on my systems. This
> >> situation would have been avoided entirely if the package manager
> >> supported multilib.
> > 
> > This one's unlikely to happen unless someone's prepared to put in
> > the work.
> 
> The multilib-portage overlay already has this working.

But there is no spec, nor is there a developer-centric description of
it.

> > So far as I know, every PM relies heavily upon bash anyway (and
> > can't easily be made not to), so even if developers would accept
> > having to rewrite all their eclasses, it still wouldn't remove the
> > dep.
> 
> Lets address POSIX compliance in the ebuilds first. Then we can deal
> with the package managers.

Why? It's highly doubtful the package manglers could switch shells even
if they wanted to, and even if every ebuild started using EAPI 5. It's
wasted effort.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk/iOG8ACgkQ96zL6DUtXhG5FgCgw3V9qz3o1d0A4TUw5y83lfCE
LWkAnRbY4WKJz1xribnhUat0YL1XEwHR
=dYt+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] My wishlist for EAPI 5

[Richard Yao]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao <ryao@gentoo.org>
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> <ryao@gentoo.org> wrote:
>>>> Multilib (and/or multiarch) support The current binaries
>>>> cause a great deal of pain, particularly when a user does not
>>>> want to upgrade something. I had this problem with WINE and
>>>> glibc because I wanted to avoid the reverse memcpy() fiasco
>>>> on my systems. This situation would have been avoided
>>>> entirely if the package manager supported multilib.
>>> 
>>> This one's unlikely to happen unless someone's prepared to put
>>> in the work.
> 
>> The multilib-portage overlay already has this working.
> 
> But there is no spec, nor is there a developer-centric description
> of it.
> 
>>> So far as I know, every PM relies heavily upon bash anyway
>>> (and can't easily be made not to), so even if developers would
>>> accept having to rewrite all their eclasses, it still wouldn't
>>> remove the dep.
> 
>> Lets address POSIX compliance in the ebuilds first. Then we can
>> deal with the package managers.
> 
> Why? It's highly doubtful the package manglers could switch shells
> even if they wanted to, and even if every ebuild started using EAPI
> 5. It's wasted effort.
> 

Source the ebuild using the system shell, check for WANT_SH. If it
does not exist, proceed. If it does, start over with a different shell.

I do not see any technical problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP4jpSAAoJECDuEZm+6ExkBqgQAJjLoTfIgSUAVk6aLzC34Pkh
+d7Q62a4jwZxh/XPG2WA2AoDX09JCIyr8yfdMTpayas1v7tdOP62IgG1Ovjfsb1g
J3Tywf3zem6jq32ju/xfWcLn2ZVRxkHvgn0J8YLPnIWBCUUBpdGqWyNxdAbGX/94
XCD6kmAMOr1EWpk3E3SQ2C1YNN/+vLX6DWW8sFEg7TZJU/5pUTnS66LIgp0ebcte
38lYHwdZGVZBLi4ehc/RSTbFtXs4vi5Q2YW32OREyMT2oyuoSqFCH4fLczvUVzF0
SKjooI0tv7dlFcXDjkEOg7fLnHioeSVyl5q/Fgz4rcyEhJuvdJu8SmqZStS5n3q3
Dd0EJ8ntUPMKcYt6g6hSczWrsKEYGSOynM+cg0WBkaTvx/J/5JVtjfsCXU707kkj
2Z/oNpjM1XgwOfnP+LY9vsBBx0y7j+EMc0/eOO8ZDxWCVsIstTtiCUhJr2TuNpDr
r2l1qVgc95JOZqGPx0/reopdM7x/8vWw+Opadg0xXZVFpvfnBlVCUH9cqFhu/DUU
ygLtZgbNnIgrlykZVLL8o8kKqKauTKpAwi1SRPjY5WIdH64lt1LEGDRfoN4BkfXZ
jjL5kT0tM9uEjt7SanG7EdJi2x0xZQolXdsaYOOgUOH1g35s0uuuQE69hEpe/TXP
wk2bZWtEPc1wDcty1/RN
=nGyi
-----END PGP SIGNATURE-----

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 20 Jun 2012 17:02:10 -0400
Richard Yao <ryao@gentoo.org> wrote:
> >> Lets address POSIX compliance in the ebuilds first. Then we can
> >> deal with the package managers.
> > 
> > Why? It's highly doubtful the package manglers could switch shells
> > even if they wanted to, and even if every ebuild started using EAPI
> > 5. It's wasted effort.
> > 
> 
> Source the ebuild using the system shell, check for WANT_SH. If it
> does not exist, proceed. If it does, start over with a different
> shell.
> 
> I do not see any technical problem.

Package managers don't "source the ebuild"... You should take a look at
the amount of horrible bash code the three PMs have, and see why it's
there.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk/iPC8ACgkQ96zL6DUtXhH6rQCghGeOb2N8iOm9F5u7k9jJkn2s
hcwAoKLB4kSHq7KaVh9D7mllQnU3U78Z
=DLvZ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] My wishlist for EAPI 5

[Richard Yao]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/20/2012 04:54 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:50:33 -0400 Richard Yao <ryao@gentoo.org>
> wrote:
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao
>>> <ryao@gentoo.org> wrote:
>>>> Multilib (and/or multiarch) support The current binaries
>>>> cause a great deal of pain, particularly when a user does not
>>>> want to upgrade something. I had this problem with WINE and
>>>> glibc because I wanted to avoid the reverse memcpy() fiasco
>>>> on my systems. This situation would have been avoided
>>>> entirely if the package manager supported multilib.
>>> 
>>> This one's unlikely to happen unless someone's prepared to put
>>> in the work.
> 
>> The multilib-portage overlay already has this working.
> 
> But there is no spec, nor is there a developer-centric description
> of it.

I missed this tibbit. I am not sure what you expect me to do this
about this. Thomas Sachau developed the multilib overlay, he has put a
great deal of work into it and he likely has a specification. You are
more than welcome to talk to him about the specification. If it not
well defined, feel free to share your ideas on how it could be better
defined.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP4jszAAoJECDuEZm+6Exk5EMP/0xRHW2PjOzb4xIEwW2ve+qM
BJNEk5lMJfL2N8x5CM30n+uUOH665fSw26o6H6mkh397F7UO+BGCctQuBgSo0q3V
s+bA3yFp5mZwr326RnnNKkgY5vKNHUjd7MH568i1ARHJdCx7Epn5Ep2o95msz0XG
yzfxFkKT1O5BXKYXyLeTNfHvyS6cRx4qIaq394u0iLOZbH8eIzZT4GPhy0KkPc0S
yeLLULtaSLQfO+F0QF/IDBC7Dupl0nxGp5cOBfsBC8Eg+mBOEHHemmKkRqv4Cv7X
kddw9bx+wjSYx0unDztyoLQ34c1XklIteOjzU+gLZtQkJ0W7+z3XQ42RwlIGPUbM
dUKsYZ2rPsKjUl0gh4Gux0PyEMkokmpygqbxd8vmE1lnAJaRR4jMgcG45jv7eSLp
ToGPNRVvuQUypmqkyIgVSCzBoplC4DkymS5oVy96GbNGNPypx3AhuAMpo8NwsH58
TNqetlVI9RQp2Yq4S930pSDmeqtel4G3zm6yJhmRfhpc28fnyrh7yzNwERKAqbpU
rExTfGd6BJul0cirkujo9ni9OOV1ue2WjBTqhp74BsBWjse5Q9J92zWmbZ9umcu0
JNJHr3wq/Fx1E4ozoYcVIKRor7T5mj7JuZpm+cyH5/GPfPZTzb0zuJy4JqbIKqHp
RfpE5eCLf16fZrB94NYz
=02/m
-----END PGP SIGNATURE-----

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 20 Jun 2012 17:05:55 -0400
Richard Yao <ryao@gentoo.org> wrote:
> >> The multilib-portage overlay already has this working.
> > 
> > But there is no spec, nor is there a developer-centric description
> > of it.
> 
> I missed this tibbit. I am not sure what you expect me to do this
> about this. Thomas Sachau developed the multilib overlay, he has put a
> great deal of work into it and he likely has a specification.

He has something, but it's nowhere near what's needed for someone to be
able to either implement it independently or produce a PMS patch.
General consensus seems to be that it needs a GLEP and a proposed diff
against PMS before anyone can even reasonably pass comment on it, let
alone accept it.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAk/iPKQACgkQ96zL6DUtXhG0xACfXFY/W9pck1Fl0qTR8vWWCCOC
VLQAoLm0SJV42+bizP1wquNZKdKxvycF
=PPkQ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] My wishlist for EAPI 5

[Richard Yao]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/20/2012 05:12 PM, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 17:05:55 -0400 Richard Yao <ryao@gentoo.org> 
> wrote:
>>>> The multilib-portage overlay already has this working.
>>> 
>>> But there is no spec, nor is there a developer-centric 
>>> description of it.
> 
>> I missed this tibbit. I am not sure what you expect me to do this
>> about this. Thomas Sachau developed the multilib overlay, he has
>> put a great deal of work into it and he likely has a 
>> specification.
> 
> He has something, but it's nowhere near what's needed for someone 
> to be able to either implement it independently or produce a PMS 
> patch. General consensus seems to be that it needs a GLEP and a 
> proposed diff against PMS before anyone can even reasonably pass 
> comment on it, let alone accept it.
> 

A new EAPI implies a GLEP.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP4kIDAAoJECDuEZm+6Exk9vMP/0dP/XzzX0zifeyfHDl4wqdc
RtfBbDX4C4Rm+5Ii8P/GbegDBxnZ+/SzBynx+d23mvNiAu1B5SKcAoa0dR5k2IIa
IiftgPbu1nfPA9ijNcdhi6VlFbjXJVllJt3Q7BfZTu8sPrKiq0Qbi4fnpJP4OFVH
XY/17GUhZy5sizpsqFIZQTggvcqVdkM99iZCey32egIhqXHM7tn8fl9StziP+dlE
4/JzkPqVCv8QojarxAGI3asQ3ysMzbVa2zRo9FGQtMi23AqiTvnakIahy6b+U5C1
holKFfTkCdp2mJAw8FHZtNeQ+DMAOSj069YTCct+fOIv6HaT5sAHYjO1ovSOkYRw
VZ0SfwTlCr8dbFCpur1YbZkfBpDuhAtJq9MbQbzuqjXQXy6y2KQlHJDi7FHJCuDl
0xKlxb1nenRk1RbxWNz6Tc530G+AkwrMnqmIlEI5X1p8J6xXwDnA7I4uAUfXhnY2
Au72AeratlSIMBYuR75ocHaaFKDhK1bG0Yu1W3Kw7hwMwaEmWHLgAr4Ne/PynwUw
/tck8Dl/F1vnnzR/YqY14rwC1b3tbuMdsGc2sO33sNHJw16EQTJklETV7KBhqQhf
wej+MTZInbOMF0m4giyohJ+6jWaAXKQhsHo8+h1SmRY/0SLuIQPySPSI01y9Gcun
PY3t9ESaVd9kZMo10trj
=/oj6
-----END PGP SIGNATURE-----

[gentoo-dev] Re: My wishlist for EAPI 5

[Duncan]

Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:

> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org> wrote:

>>> POSIX Shell compliance
>> 
>> So far as I know, every PM relies heavily upon bash anyway (and can't
>> easily be made not to), so even if developers would accept having to
>> rewrite all their eclasses, it still wouldn't remove the dep.
>> 
> Lets address POSIX compliance in the ebuilds first. Then we can deal
> with the package managers.

Additionally, this is extremely unlikely because a number of developers 
insist on bash, to the extent that it would likely split gentoo in half 
if this were to be forced.  It wouldn't pass council.  It's unlikely to 
even /get/ to council.

Openrc could move to POSIX shell because its primary dev at the time 
wanted it that way and it's only a single package.  However, even then, 
doing it was controversial enough that said developer ended up leaving 
gentoo in-part over that, tho he did continue to develop openrc as a 
gentoo hosted project for quite some years.  Now you're talking trying to 
do it for /every/ (well, almost every) package, thus touching every 
single gentoo dev.  It's just not going to happen in even the medium term 
(say for argument APIs 5-7ish), let alone be something practical enough 
to implement, soon enough (even if everyone agreed on the general idea, 
they don't), to be anything like conceivable for EAPI5.

So just let that one be.  It's simply not worth tilting at that windmill.

(Arguably, multi-arch, while practical and actually working at least with 
portage in an overlay, fails that last bit as well.  If it was pushed, 
perhaps for EAPI6 or 7, but it's just not practical to consider it for 
EAPI5... unless you want to wait 3-5 years for EAPI5!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Richard Yao]

On 06/21/2012 04:29 AM, Duncan wrote:
> Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:
>
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org> wrote:
>>>> POSIX Shell compliance
>>> So far as I know, every PM relies heavily upon bash anyway (and can't
>>> easily be made not to), so even if developers would accept having to
>>> rewrite all their eclasses, it still wouldn't remove the dep.
>>>
>> Lets address POSIX compliance in the ebuilds first. Then we can deal
>> with the package managers.
> Additionally, this is extremely unlikely because a number of developers 
> insist on bash, to the extent that it would likely split gentoo in half 
> if this were to be forced.  It wouldn't pass council.  It's unlikely to 
> even /get/ to council.
>
> Openrc could move to POSIX shell because its primary dev at the time 
> wanted it that way and it's only a single package.  However, even then, 
> doing it was controversial enough that said developer ended up leaving 
> gentoo in-part over that, tho he did continue to develop openrc as a 
> gentoo hosted project for quite some years.  Now you're talking trying to 
> do it for /every/ (well, almost every) package, thus touching every 
> single gentoo dev.  It's just not going to happen in even the medium term 
> (say for argument APIs 5-7ish), let alone be something practical enough 
> to implement, soon enough (even if everyone agreed on the general idea, 
> they don't), to be anything like conceivable for EAPI5.
>
> So just let that one be.  It's simply not worth tilting at that windmill.
>
> (Arguably, multi-arch, while practical and actually working at least with 
> portage in an overlay, fails that last bit as well.  If it was pushed, 
> perhaps for EAPI6 or 7, but it's just not practical to consider it for 
> EAPI5... unless you want to wait 3-5 years for EAPI5!)
>
It is just a wish list.

Anyway, people need to decide on what they want from a new EAPI before
one is made. Once they decide, it should be possible to work out the
details.

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Richard Yao]

On 06/21/2012 04:29 AM, Duncan wrote:
> Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:
> 
>> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org> wrote:
> 
>>>> POSIX Shell compliance
>>>
>>> So far as I know, every PM relies heavily upon bash anyway (and can't
>>> easily be made not to), so even if developers would accept having to
>>> rewrite all their eclasses, it still wouldn't remove the dep.
>>>
>> Lets address POSIX compliance in the ebuilds first. Then we can deal
>> with the package managers.
> 
> Additionally, this is extremely unlikely because a number of developers 
> insist on bash, to the extent that it would likely split gentoo in half 
> if this were to be forced.  It wouldn't pass council.  It's unlikely to 
> even /get/ to council.
> 
> Openrc could move to POSIX shell because its primary dev at the time 
> wanted it that way and it's only a single package.  However, even then, 
> doing it was controversial enough that said developer ended up leaving 
> gentoo in-part over that, tho he did continue to develop openrc as a 
> gentoo hosted project for quite some years.  Now you're talking trying to 
> do it for /every/ (well, almost every) package, thus touching every 
> single gentoo dev.  It's just not going to happen in even the medium term 
> (say for argument APIs 5-7ish), let alone be something practical enough 
> to implement, soon enough (even if everyone agreed on the general idea, 
> they don't), to be anything like conceivable for EAPI5.
> 
> So just let that one be.  It's simply not worth tilting at that windmill.

Would you (or someone else) elaborate on the specific features of bash
that people find attractive?

[gentoo-dev] Re: My wishlist for EAPI 5

[Duncan]

Richard Yao posted on Thu, 21 Jun 2012 20:38:17 -0400 as excerpted:

> Would you (or someone else) elaborate on the specific features of bash
> that people find attractive?

For me (not a gentoo dev), in simplest terms it's just that I don't like 
having to keep track of what's a bashism and what's POSIX.  If individual 
devs prefer POSIX code, they can certainly write ebuilds (or a 4th gentoo 
package manager for that matter) in all POSIX, but there's enough devs 
that for /whatever/ reason strongly prefer bash, where "strongly" is 
ultimately defined as "if it's redefined to POSIX, there's a lot of other 
projects I can spend my time on instead, that won't force me into jumping 
thru those hoops", and that fact is widely enough known, that it's 
unlikely in the extreme.

But to give you a example I've seen on this list (one of the few bits I 
know isn't POSIX)...  Many people appreciate the advantages of [[ tests, 
looser quoting, ==/=~ pattern matching tests, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Michał Górny]

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

On Thu, 21 Jun 2012 20:38:17 -0400
Richard Yao <ryao@gentoo.org> wrote:

> On 06/21/2012 04:29 AM, Duncan wrote:
> > Richard Yao posted on Wed, 20 Jun 2012 16:50:33 -0400 as excerpted:
> > 
> >> On 06/20/2012 04:35 PM, Ciaran McCreesh wrote:
> >>> On Wed, 20 Jun 2012 16:25:30 -0400 Richard Yao <ryao@gentoo.org>
> >>> wrote:
> > 
> >>>> POSIX Shell compliance
> >>>
> >>> So far as I know, every PM relies heavily upon bash anyway (and
> >>> can't easily be made not to), so even if developers would accept
> >>> having to rewrite all their eclasses, it still wouldn't remove
> >>> the dep.
> >>>
> >> Lets address POSIX compliance in the ebuilds first. Then we can
> >> deal with the package managers.
> > 
> > Additionally, this is extremely unlikely because a number of
> > developers insist on bash, to the extent that it would likely split
> > gentoo in half if this were to be forced.  It wouldn't pass
> > council.  It's unlikely to even /get/ to council.
> > 
> > Openrc could move to POSIX shell because its primary dev at the
> > time wanted it that way and it's only a single package.  However,
> > even then, doing it was controversial enough that said developer
> > ended up leaving gentoo in-part over that, tho he did continue to
> > develop openrc as a gentoo hosted project for quite some years.
> > Now you're talking trying to do it for /every/ (well, almost every)
> > package, thus touching every single gentoo dev.  It's just not
> > going to happen in even the medium term (say for argument APIs
> > 5-7ish), let alone be something practical enough to implement, soon
> > enough (even if everyone agreed on the general idea, they don't),
> > to be anything like conceivable for EAPI5.
> > 
> > So just let that one be.  It's simply not worth tilting at that
> > windmill.
> 
> Would you (or someone else) elaborate on the specific features of bash
> that people find attractive?

Local variables, reasonable behavior (like 'FOO=abc bar' where bar is
macro), arrays, [[ ]] tests (which are obviously faster than calling
external test program).

One more use: printing useful die messages (in POSIX sh there's no way
to do a backtrace).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Ben de Groot]

On 22 June 2012 08:38, Richard Yao <ryao@gentoo.org> wrote:
> Would you (or someone else) elaborate on the specific features of bash
> that people find attractive?

For me, it is mostly [[ ]] tests, arrays and brace expansion.
The += operator is also very nice to have.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

Re: [gentoo-dev] My wishlist for EAPI 5

[Justin]

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

On 20.06.2012 22:35, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 16:25:30 -0400
> Richard Yao <ryao@gentoo.org> wrote:
>> Multilib (and/or multiarch) support
>> 	The current binaries cause a great deal of pain, particularly
>> when a user does not want to upgrade something. I had this problem
>> with WINE and glibc because I wanted to avoid the reverse memcpy()
>> fiasco on my systems. This situation would have been avoided entirely
>> if the package manager supported multilib.
> 
> This one's unlikely to happen unless someone's prepared to put in the
> work.

Tommy worked a lot on this and he asked for help to bring his
proposal/spec/glep into shape.
We are all aware what this is all about and know that anybody who is
using multilib would benefit.
Can't you simply work with him together to get it into what you expect
it to be instead of pointing out that it isn't?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El mié, 20-06-2012 a las 23:43 +0200, Justin escribió:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao <ryao@gentoo.org> wrote:
> >> Multilib (and/or multiarch) support
> >> 	The current binaries cause a great deal of pain, particularly
> >> when a user does not want to upgrade something. I had this problem
> >> with WINE and glibc because I wanted to avoid the reverse memcpy()
> >> fiasco on my systems. This situation would have been avoided entirely
> >> if the package manager supported multilib.
> > 
> > This one's unlikely to happen unless someone's prepared to put in the
> > work.
> 
> Tommy worked a lot on this and he asked for help to bring his
> proposal/spec/glep into shape.
> We are all aware what this is all about and know that anybody who is
> using multilib would benefit.
> Can't you simply work with him together to get it into what you expect
> it to be instead of pointing out that it isn't?
> 

Also, if I remember correctly, Tommy asked for this some months ago, you
asked for what he sent some days ago and now you require more and more
work to delay things to be implemented. I also don't understand why
Gentoo is forced to stick with old ways of doing things until new EAPI
is approved while Exherbo is free to implement and use things like that
special way of handling DEPENDENCIES without waiting for any EAPI to be
accepted... or maybe I am wrong and people is able to use any PM manager
compliant with EAPI on exherbo without issues?

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Thu, 21 Jun 2012 08:08:55 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Also, if I remember correctly, Tommy asked for this some months ago,
> you asked for what he sent some days ago and now you require more and
> more work to delay things to be implemented.

I still haven't seen a clear description of exactly what should be
changed and why. I've also not seen a description of exactly what
problem is being solved, nor a discussion of the relative merits of
implementing a solution to whatever that problem is. All I've seen is a
mess of code that "gets it working" in Portage (which isn't the same as
"implements it for Portage") and a big wall of text that contains lots
that no-one needs to know and little of what's important. This needs to
go through the GLEP process, and it needs a PMS diff.

In case you're not aware, the first time Gentoo did multilib, it was
done as a series of random changes to Portage that no-one really
thought through or understood. As you can see, that didn't work...

> I also don't understand why Gentoo is forced to stick with old ways
> of doing things until new EAPI is approved

That's not what's going on here. The issue is that there might be one
person who understands what "the new way of doing things", but he
hasn't told us what he thinks that is. Once we get a proper
explanation, getting an EAPI out doesn't take long.

The main problem here isn't even EAPI related. Ebuild developers don't
even know what they'll be expected, required or able to do for multilib.

> while Exherbo is free to implement and use things like that special
> way of handling DEPENDENCIES without waiting for any EAPI to be
> accepted...

The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
have it because Portage couldn't implement it. Now it doesn't have it
because it's too controversial to get it approved. Exherbo does have it
because it was carefully discussed, compared to alternatives, planned
out, tested, accepted by the expendable figurehead, and then rolled out.

> or maybe I am wrong and people is able to use any PM manager
> compliant with EAPI on exherbo without issues?

If anyone ever manages to come up with another package mangler that can
get close to implementing what Exherbo needs, then sure.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> On Thu, 21 Jun 2012 08:08:55 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Also, if I remember correctly, Tommy asked for this some months ago,
> > you asked for what he sent some days ago and now you require more and
> > more work to delay things to be implemented.
> 
> I still haven't seen a clear description of exactly what should be
> changed and why. I've also not seen a description of exactly what
> problem is being solved, nor a discussion of the relative merits of
> implementing a solution to whatever that problem is. All I've seen is a
> mess of code that "gets it working" in Portage (which isn't the same as
> "implements it for Portage") and a big wall of text that contains lots
> that no-one needs to know and little of what's important. This needs to
> go through the GLEP process, and it needs a PMS diff.
> 
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work...
> 

Then, looks clear to me that the way to get things approved in newer
EAPIs is not clear enough as looks like a lot of devs (like me) don't
know them (for example, when things to be added to EAPI need also a GLEP
and a PMS diff, also the needing to get an implementation for any
package manager). Is this documented in some place? If not, I think it
should be documented and, of course, it should be done by PMS team if
possible as they clearly know what they expect to get for approval if
needed since, I discussed some days ago, council will simply accept some
specific features to be included in next eapi once they are accepted by
PMS team. That way, we could save a lot of time, know what steps are
pending, try to ask for help for some specific steps and, finally, get
it discussed in PMS people providing all what is needed.


> > I also don't understand why Gentoo is forced to stick with old ways
> > of doing things until new EAPI is approved
> 
> That's not what's going on here. The issue is that there might be one
> person who understands what "the new way of doing things", but he
> hasn't told us what he thinks that is. Once we get a proper
> explanation, getting an EAPI out doesn't take long.
> 

But you must confess that old problems like multilib support, force
package rebuilding or optional dep support are still pending while still
needing and, the problem with the way things are discussed now is that
some day anybody arises the problem again, other one demands more things
to be provided, a discussion starts, the problem gets stalled... one
year later the same problem arises again. There is clearly a lack of
information to the rest of developers about how to propose anything to
get accepted for next EAPI.

> The main problem here isn't even EAPI related. Ebuild developers don't
> even know what they'll be expected, required or able to do for multilib.
> 
> > while Exherbo is free to implement and use things like that special
> > way of handling DEPENDENCIES without waiting for any EAPI to be
> > accepted...
> 
> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
> have it because Portage couldn't implement it. Now it doesn't have it
> because it's too controversial to get it approved. 

It was only a example, but thanks for the info :)

> Exherbo does have it
> because it was carefully discussed, compared to alternatives, planned
> out, tested, accepted by the expendable figurehead, and then rolled out.
> 
> > or maybe I am wrong and people is able to use any PM manager
> > compliant with EAPI on exherbo without issues?
> 
> If anyone ever manages to come up with another package mangler that can
> get close to implementing what Exherbo needs, then sure.
> 

Then, you accept exherbo is not forced to *only* follow EAPI while you
force Gentoo and portage to only support features approved in an EAPI?


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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Thu, 21 Jun 2012 09:25:10 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Then, looks clear to me that the way to get things approved in newer
> EAPIs is not clear enough as looks like a lot of devs (like me) don't
> know them (for example, when things to be added to EAPI need also a
> GLEP and a PMS diff, also the needing to get an implementation for any
> package manager).

That's very much a judgement call. If a feature is "easy", low impact
and uncontroversial, you can ask for it on IRC, the mailing lists or
bugzilla, and chances are someone will do all the work for you. If it's
a big feature with broad impact requiring lots of changes, you need to
do however much work is necessary such that a) the people working on
PMS understand it well enough to document it, b) developers understand
it well enough to know what it involves for them, c) the Council can
compare and contrast it with other proposals, and d) it can be
implemented.

The "implement it in a package manager" thing is because of what
happened with REQUIRED_USE. It hadn't been implemented previously, and
as it turns out it has some fairly hefty usability issues.

> > > I also don't understand why Gentoo is forced to stick with old
> > > ways of doing things until new EAPI is approved
> > 
> > That's not what's going on here. The issue is that there might be
> > one person who understands what "the new way of doing things", but
> > he hasn't told us what he thinks that is. Once we get a proper
> > explanation, getting an EAPI out doesn't take long.
> > 
> 
> But you must confess that old problems like multilib support, force
> package rebuilding or optional dep support are still pending while
> still needing and, the problem with the way things are discussed now
> is that some day anybody arises the problem again, other one demands
> more things to be provided, a discussion starts, the problem gets
> stalled... one year later the same problem arises again. There is
> clearly a lack of information to the rest of developers about how to
> propose anything to get accepted for next EAPI.

The reason those are still pending is because no-one knows what the
*problem* is, let alone the solution. That's not an EAPI issue, it's a
developers saying "I want a flying unicorn!" issue.

> Then, you accept exherbo is not forced to *only* follow EAPI while you
> force Gentoo and portage to only support features approved in an EAPI?

I think you have a severe misunderstanding of what the EAPI process is
about here... It's not about forcing anything. The point of the EAPI
process is to allow Gentoo to roll things out without requiring
developers to rewrite all their ebuilds every few months (which
happens on Exherbo, incidentally), and without breaking user systems.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El jue, 21-06-2012 a las 08:39 +0100, Ciaran McCreesh escribió:
> On Thu, 21 Jun 2012 09:25:10 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Then, looks clear to me that the way to get things approved in newer
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't
> > know them (for example, when things to be added to EAPI need also a
> > GLEP and a PMS diff, also the needing to get an implementation for any
> > package manager).
> 
> That's very much a judgement call. If a feature is "easy", low impact
> and uncontroversial, you can ask for it on IRC, the mailing lists or
> bugzilla, and chances are someone will do all the work for you.

That cannot be the way of doing things, who is the once deciding a
feature is "easy"? Is something like:
https://bugs.gentoo.org/show_bug.cgi?id=357561

easy enough? Looks like it's getting so much time to get it done that we
are now needing to rely on eclasses and manual removal to handle it.

>  If it's
> a big feature with broad impact requiring lots of changes, you need to
> do however much work is necessary such that a) the people working on
> PMS understand it well enough to document it, b) developers understand
> it well enough to know what it involves for them, c) the Council can
> compare and contrast it with other proposals, and d) it can be
> implemented.
> 
> The "implement it in a package manager" thing is because of what
> happened with REQUIRED_USE. It hadn't been implemented previously, and
> as it turns out it has some fairly hefty usability issues.

Look for example to multilib stuff, looks like mails explaining the
issue and how tommy wants to fix it are not enough (I don't mean only
the last thread about this problem,  I remember he sending more mails
explaining the issue months ago), Tommy is also providing PMS people an
implementation... and now you come demanding more and more things. If
all requirements would be clear from start, this shouldn't occur and all
of us would save a lot of time and problems between us.

> 
> > > > I also don't understand why Gentoo is forced to stick with old
> > > > ways of doing things until new EAPI is approved
> > > 
> > > That's not what's going on here. The issue is that there might be
> > > one person who understands what "the new way of doing things", but
> > > he hasn't told us what he thinks that is. Once we get a proper
> > > explanation, getting an EAPI out doesn't take long.
> > > 
> > 
> > But you must confess that old problems like multilib support, force
> > package rebuilding or optional dep support are still pending while
> > still needing and, the problem with the way things are discussed now
> > is that some day anybody arises the problem again, other one demands
> > more things to be provided, a discussion starts, the problem gets
> > stalled... one year later the same problem arises again. There is
> > clearly a lack of information to the rest of developers about how to
> > propose anything to get accepted for next EAPI.
> 
> The reason those are still pending is because no-one knows what the
> *problem* is, let alone the solution.

Seriously, don't you know what are the problems of current way of
handling emul packages? :O

>  That's not an EAPI issue, it's a
> developers saying "I want a flying unicorn!" issue.
> 
> > Then, you accept exherbo is not forced to *only* follow EAPI while you
> > force Gentoo and portage to only support features approved in an EAPI?
> 
> I think you have a severe misunderstanding of what the EAPI process is
> about here... It's not about forcing anything. The point of the EAPI
> process is to allow Gentoo to roll things out without requiring
> developers to rewrite all their ebuilds every few months (which
> happens on Exherbo, incidentally), and without breaking user systems.
> 

Then, I guess we could have something like GEAPI that would require only
agreement between gentoo people (and people wanting to reach a
consensus) that would also prevent people from needing to rewrite their
ebuilds from time to time? 

Don't you see this way of handling things, with such and obscure way of
getting things accepted for every EAPI is really hurting us? If all of
us would want to reach consensus it wouldn't be so problematic but, when
some people is simply waiting every proposal (even with implementation
and after more tries to get it accepted) to ask them for more and more
work and, when anybody ask for help to accomplish that, the same one
refuses to help if he is not payed for that, this only causes Gentoo to
lack some important features for ages.

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 09:53:37 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Don't you see this way of handling things, with such and obscure way
> of getting things accepted for every EAPI is really hurting us?

What is hurting is people demanding features without specifying what
the problem is, how it will be solved or what the impact on users or
developers will be, and then taking up everyone's time with complaints
when they don't get magical flying unicorns instantly.

If you want something, you either have to do the work yourself, or find
someone to do it. And here's the thing: you're assuming that "the work"
is trivial, which for some of the things you're discussing it really
isn't. The PMS wording is the trivial bit that comes at the end once
the problem and solution have been worked out.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Peter Stuge]

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

Ciaran McCreesh wrote:
> What is hurting is people demanding features without specifying what
> the problem is

Part of enabling progress is to show a strong will to communicate,
with the goal of extracting common understanding from discussion.

In any project based on volunteer effort you must show that you too
are interested in giving, for anyone to give you anything.

When it's not obvious that you want to receive - to the point where
you drive the discussion (the horror!) in order to arrive at that
point of common understanding - then people will be upset and look
down on you, because dealing with you leaves too sour a taste behind.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió:
> Ciaran McCreesh wrote:
> > What is hurting is people demanding features without specifying what
> > the problem is
> 
> Part of enabling progress is to show a strong will to communicate,
> with the goal of extracting common understanding from discussion.
> 
> In any project based on volunteer effort you must show that you too
> are interested in giving, for anyone to give you anything.
> 
> When it's not obvious that you want to receive - to the point where
> you drive the discussion (the horror!) in order to arrive at that
> point of common understanding - then people will be upset and look
> down on you, because dealing with you leaves too sour a taste behind.
> 
> 
> //Peter

As Peter explains, I think it is now clear enough what I was demanding
(about clarifying what is needed to get things in next EAPI to prevent
issues like Tommy is suffering to get multilib stuff done), but I star
to think Ciaran thinks it's easier to simply wear a blindfold on to keep
thinking all what he says cannot be corrected at all, neither improved
and others must follow his instructions blindly

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El sáb, 23-06-2012 a las 12:24 +0200, Pacho Ramos escribió:
> El sáb, 23-06-2012 a las 11:53 +0200, Peter Stuge escribió:
> > Ciaran McCreesh wrote:
> > > What is hurting is people demanding features without specifying what
> > > the problem is
> > 
> > Part of enabling progress is to show a strong will to communicate,
> > with the goal of extracting common understanding from discussion.
> > 
> > In any project based on volunteer effort you must show that you too
> > are interested in giving, for anyone to give you anything.
> > 
> > When it's not obvious that you want to receive - to the point where
> > you drive the discussion (the horror!) in order to arrive at that
> > point of common understanding - then people will be upset and look
> > down on you, because dealing with you leaves too sour a taste behind.
> > 
> > 
> > //Peter
> 
> As Peter explains, I think it is now clear enough what I was demanding
> (about clarifying what is needed to get things in next EAPI to prevent
> issues like Tommy is suffering to get multilib stuff done), but I star
> to think Ciaran thinks it's easier to simply wear a blindfold on to keep
> thinking all what he says cannot be corrected at all, neither improved
> and others must follow his instructions blindly

Ciaran, simply think that, if PMS team agrees with a doc explaining what
needs to be provided and the procedure, you will also save time and not
need to follow this tedious discussions, all parts will benefit for
sure.

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 12:24:32 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> As Peter explains, I think it is now clear enough what I was demanding
> (about clarifying what is needed to get things in next EAPI to prevent
> issues like Tommy is suffering to get multilib stuff done), but I star
> to think Ciaran thinks it's easier to simply wear a blindfold on to
> keep thinking all what he says cannot be corrected at all, neither
> improved and others must follow his instructions blindly

Oh come on. You're just shooting the messenger. You don't like being
told that if you want something, someone needs to do the work, and you
can't just say "I want a flying unicorn!" and expect it to happen.

I'm not the only one saying it, either. I point you to this, for
example:

http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml

> Ciaran, simply think that, if PMS team agrees with a doc explaining
> what needs to be provided and the procedure, you will also save time
> and not need to follow this tedious discussions, all parts will
> benefit for sure.

The procedure is not the important part. The important part is finding
someone who can do enough of the work that the PMS team can understand
your proposal and polish off the rough edges. The work that needs to be
done for that is very much a case by case thing, and it's not just a
simple list of steps that anyone can follow blindly. The features
you're asking for that aren't magically appearing are hard.

I'll remind you that for "big" features, the GLEP process is already
documented.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El sáb, 23-06-2012 a las 11:31 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 12:24:32 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > As Peter explains, I think it is now clear enough what I was demanding
> > (about clarifying what is needed to get things in next EAPI to prevent
> > issues like Tommy is suffering to get multilib stuff done), but I star
> > to think Ciaran thinks it's easier to simply wear a blindfold on to
> > keep thinking all what he says cannot be corrected at all, neither
> > improved and others must follow his instructions blindly
> 
> Oh come on. You're just shooting the messenger. You don't like being
> told that if you want something, someone needs to do the work, and you
> can't just say "I want a flying unicorn!" and expect it to happen.
> 
> I'm not the only one saying it, either. I point you to this, for
> example:
> 
> http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml

That shows how things can be done and how shouldn't be done, it's not
casual that you are always involved in this kind of discussions, instead
of thinking all people is trying to "shoot the messenger", maybe you
should think about you acts here (I know it's difficult, specially when
discussions are done virtually and not in real world where you,
probably, would understand better that your way of demanding things and
putting conditions is not the way to go). Making constructive
suggestions instead of others that can be easily interpreted as whims is
the way to go.

> 
> > Ciaran, simply think that, if PMS team agrees with a doc explaining
> > what needs to be provided and the procedure, you will also save time
> > and not need to follow this tedious discussions, all parts will
> > benefit for sure.
> 
> The procedure is not the important part. The important part is finding
> someone who can do enough of the work that the PMS team can understand
> your proposal and polish off the rough edges. The work that needs to be
> done for that is very much a case by case thing, and it's not just a
> simple list of steps that anyone can follow blindly. The features
> you're asking for that aren't magically appearing are hard.
> 
> I'll remind you that for "big" features, the GLEP process is already
> documented.
> 

You know what I exactly mean, don't try to change the topic to "GLEP
process is already documented" to hide you don't want to put anything of
your time to help others to get proper documentation prepared to show to
pms team. Of course, you have the right to do so as this is all
contribution work that we do it if we want and have time, but don't try
to hide it in this way.

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 13:05:51 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> > http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml
> 
> That shows how things can be done and how shouldn't be done, it's not
> casual that you are always involved in this kind of discussions,

Yes, because I'm prepared to put in the work to make sure these things
get done properly, whereas others will just comment once and then
ignore the rest of the thread.

> instead of thinking all people is trying to "shoot the messenger",
> maybe you should think about you acts here (I know it's difficult,
> specially when discussions are done virtually and not in real world
> where you, probably, would understand better that your way of
> demanding things and putting conditions is not the way to go). Making
> constructive suggestions instead of others that can be easily
> interpreted as whims is the way to go.

Uh huh, and that's what I've been doing the whole time when I've been
asking for a patch for PMS, a GLEP etc.

> > I'll remind you that for "big" features, the GLEP process is already
> > documented.
> 
> You know what I exactly mean, don't try to change the topic to "GLEP
> process is already documented" to hide you don't want to put anything
> of your time to help others to get proper documentation prepared to
> show to pms team. Of course, you have the right to do so as this is
> all contribution work that we do it if we want and have time, but
> don't try to hide it in this way.

That's nonsense. I've put in a lot of work on the PMS side for features
that I understand. If multilib gets beyond what Brian called "a fairly 
opaque list of things", *then* I'm quite happy to help if I'm able.
Right now, though, there's nowhere near enough that I (or as far as I
can see, anyone else) can even start to go anywhere with it.

This isn't going nowhere because no-one wants to help. It's going
nowhere because what's been presented so far is nowhere near enough
that anyone *can* help, and requests for a better description of what
we're supposed to be looking at are being met with complaints that we
haven't magically done all of the remaining work (which on this one I
suspect is far more effort than what's been done so far).

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Peter Stuge]

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

Ciaran McCreesh wrote:
> > Making constructive suggestions instead of others that can be
> > easily interpreted as whims is the way to go.
> 
> Uh huh, and that's what I've been doing the whole time when I've
> been asking for a patch for PMS, a GLEP etc.
..
> requests for a better description we're supposed to be looking at

No, this isn't really constructive. As I wrote, try to drive the
discussion by adding substance to it, rather than fueling flames
by requesting others to refine.

Since it is an area where you may be able to contribute, I think
it would be great if you did!


> are being met with complaints that we haven't magically done all
> of the remaining work

I think you're right that complaints are about your response, but I
absolutely do not interpret the complaints to be that you personally
or the PMS team did not implement the requested feature. I think
that's a misunderstanding of yours.

If you don't understand something of what thus far has been written,
then why not ask specific questions to fill those gaps, and move on?


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 13:38:09 +0200
Peter Stuge <peter@stuge.se> wrote:
> If you don't understand something of what thus far has been written,
> then why not ask specific questions to fill those gaps, and move on?

The multilib material isn't at the point where specific questions can be
asked. Brian's description of it as an "opaque list of things" is
pretty much spot on. That's why we want a GLEP and a PMS diff -- an
attempt at those might bring this to the point where we can say
something other than "huh?".

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Peter Stuge]

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

Ciaran McCreesh wrote:
> bring this to the point where we can say something other than "huh?".

You can accelerate by making one guess about each thing on the list
and asking for confirmation of your guess.

It sounds silly, but I realized that this actually happens all the
time offline - at least to me. I interpret, ask if I got it right,
then move on. It's pretty efficient, but requires both sender and
receiver wanting successful transmission.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 13:52:24 +0200
Peter Stuge <peter@stuge.se> wrote:
> Ciaran McCreesh wrote:
> > bring this to the point where we can say something other than
> > "huh?".
> 
> You can accelerate by making one guess about each thing on the list
> and asking for confirmation of your guess.
> 
> It sounds silly, but I realized that this actually happens all the
> time offline - at least to me. I interpret, ask if I got it right,
> then move on. It's pretty efficient, but requires both sender and
> receiver wanting successful transmission.

The issue is not that we don't understand the list. The issue is that
we don't understand the problem (beyond superficially), how the
proposed solution works from an ebuild perspective, whether the
solution solves the problem, or how it all fits together. Most of the
stuff on the list is irrelevant from a design perspective. It's not
that the list is hard to understand, it's that understanding the
problem and solution requires completely different material.

To take one example, figuring out exactly which variables get mangled
is an unimportant detail at this stage (and likely we'll want to
offload it to profiles, not hard-code it in PMS) and not a central part
of the proposal.

What we need is a GLEP, describing it in high level terms with a
discussion upon how it impacts users and ebuild developers, and a PMS
patch, highlighting what's to be changed in specific technical terms.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El sáb, 23-06-2012 a las 12:59 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 13:52:24 +0200
> Peter Stuge <peter@stuge.se> wrote:
> > Ciaran McCreesh wrote:
> > > bring this to the point where we can say something other than
> > > "huh?".
> > 
> > You can accelerate by making one guess about each thing on the list
> > and asking for confirmation of your guess.
> > 
> > It sounds silly, but I realized that this actually happens all the
> > time offline - at least to me. I interpret, ask if I got it right,
> > then move on. It's pretty efficient, but requires both sender and
> > receiver wanting successful transmission.
> 
> The issue is not that we don't understand the list. The issue is that
> we don't understand the problem (beyond superficially), how the
> proposed solution works from an ebuild perspective, whether the
> solution solves the problem, or how it all fits together. Most of the
> stuff on the list is irrelevant from a design perspective. It's not
> that the list is hard to understand, it's that understanding the
> problem and solution requires completely different material.
> 
> To take one example, figuring out exactly which variables get mangled
> is an unimportant detail at this stage (and likely we'll want to
> offload it to profiles, not hard-code it in PMS) and not a central part
> of the proposal.
> 
> What we need is a GLEP, describing it in high level terms with a
> discussion upon how it impacts users and ebuild developers, and a PMS
> patch, highlighting what's to be changed in specific technical terms.
> 

What we *also* need is to document this requirements to let people
present that work directly instead of losing days figuring out what is
needed or what not

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 14:16:13 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> What we *also* need is to document this requirements to let people
> present that work directly instead of losing days figuring out what is
> needed or what not

The requirement is that the PMS team needs to be able to understand the
proposal, and that someone needs to do however much work is necessary
(which varies massively from proposal to proposal -- multilib is
at least a thousand times more complicated than adding a new function
that outputs stuff based upon a use flag) to be able to present it in a
form acceptable to the Council. That's all there is to it. There is no
lengthy form P123b.5 to fill in or anything like that.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El sáb, 23-06-2012 a las 12:37 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 13:38:09 +0200
> Peter Stuge <peter@stuge.se> wrote:
> > If you don't understand something of what thus far has been written,
> > then why not ask specific questions to fill those gaps, and move on?
> 
> The multilib material isn't at the point where specific questions can be
> asked. Brian's description of it as an "opaque list of things" is
> pretty much spot on. That's why we want a GLEP and a PMS diff -- an
> attempt at those might bring this to the point where we can say
> something other than "huh?".
> 

Looks like you have now opted to use Brian's comment as a kind of
"shield" of similar and discuss only about multilib, even when this
thread was more general and we were talking to the problems shown in
recent discussions (from forcing rebuilds issue, optional deps problems
to some trivial questions like know where we can see what things are
being worked out for eapi5). 

In all that discussions there were a clear tendency to always say "it's
fine the way it's", even when a lot of people didn't even know what
things were going to be included in eapi5, or discuss for days about the
forcing rebuilds issue (with the, now classical, glib vs dbus-glib/g-i
issue) to finally still tell people "we still didn't fully know what the
problem was". I remember that, just after Brian and Zac's comments about
trying to clarify things a bit on that thread and reach a solution, your
reply to them was that we were missing a brilliant opportunity to
"encourage developers put in a bit more work to save users a huge amount
of pain here". Personally, I see a clear difference about their way to
show their disagreement and yours.

Of course, I know how this thread will end: once we decide to stop
replying (or anybody asks us to stop) as you seem to find this happy or
so and, of course, you will always say the last word, the problem will
get stalled until three months later somebody else rises the problem
again letting you to show again that "always rejecting position" you
seem to like.

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 14:11:28 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Looks like you have now opted to use Brian's comment as a kind of
> "shield" of similar and discuss only about multilib, even when this
> thread was more general and we were talking to the problems shown in
> recent discussions (from forcing rebuilds issue, optional deps
> problems to some trivial questions like know where we can see what
> things are being worked out for eapi5). 

For optional deps, we're close to having two proposals. That's moving
forwards. Whether or not it will be in EAPI 5 depends solely upon
timing, and whether the Council ends up liking at least one of the two
proposals.

For "forced rebuilds", there's a proposal already, and Zac has just
done implementation work, and most of the PMS patch was written ages
ago for kdebuild-1 and the original EAPI 3. So again, whether or not
that ends up in EAPI 5 is just a matter of timing and Council approval.

For "what's being worked on", you just need to look at the PMS list.

So I'm really not sure what your problem is there...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El sáb, 23-06-2012 a las 13:16 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 14:11:28 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Looks like you have now opted to use Brian's comment as a kind of
> > "shield" of similar and discuss only about multilib, even when this
> > thread was more general and we were talking to the problems shown in
> > recent discussions (from forcing rebuilds issue, optional deps
> > problems to some trivial questions like know where we can see what
> > things are being worked out for eapi5). 
> 
> For optional deps, we're close to having two proposals. That's moving
> forwards. Whether or not it will be in EAPI 5 depends solely upon
> timing, and whether the Council ends up liking at least one of the two
> proposals.
> 
> For "forced rebuilds", there's a proposal already, and Zac has just
> done implementation work, and most of the PMS patch was written ages
> ago for kdebuild-1 and the original EAPI 3. So again, whether or not
> that ends up in EAPI 5 is just a matter of timing and Council approval.
> 
> For "what's being worked on", you just need to look at the PMS list.
> 
> So I'm really not sure what your problem is there...
> 

Your cynicism, that is the problem I see

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

[gentoo-dev] Re: My wishlist for EAPI 5

[Duncan]

Ciaran McCreesh posted on Sat, 23 Jun 2012 10:38:33 +0100 as excerpted:

> On Sat, 23 Jun 2012 09:53:37 +0200 Pacho Ramos <pacho@gentoo.org> wrote:
>> Don't you see this way of handling things, with such and obscure way of
>> getting things accepted for every EAPI is really hurting us?
> 
> What is hurting is people demanding features without specifying what the
> problem is, how it will be solved or what the impact on users or
> developers will be, and then taking up everyone's time with complaints
> when they don't get magical flying unicorns instantly.
> 
> If you want something, you either have to do the work yourself, or find
> someone to do it. And here's the thing: you're assuming that "the work"
> is trivial, which for some of the things you're discussing it really
> isn't. The PMS wording is the trivial bit that comes at the end once the
> problem and solution have been worked out.

Without weighing in on either side of the technical details of this 
debate, it's possible to observe two things:

1) Fact: Unfortunately, your method of argument, Ciaran, doesn't endear 
you to a number of devs.  Some may have the impulse to reject an argument 
simply because it comes from you.

2) PMS is supposed to be about specifying things well enough that all 
three PMs can implement compatible ebuild/eclass/etc interpretation and 
execution.

3) Given the above, it would be of /great/ benefit to your argument if 
either Zac or Brian (or preferably both) stepped up from time to time and 
said yes, this is really an issue.

Not that they'd necessarily reply to everything you do, but if they could 
reply once in support, such that you could refer people back to those 
replies from elsewhere...

This would be of particular help concerning the multi-arch work where 
there's already an implementation for portage, but it is argued a proper 
spec is still lacking.  Obviously if it's approved Brian's going to need 
to implement it as well as you, and having him too say there's not enough 
there to do so, ideally with his estimation of where the process is in 
terms of work needed, as well, would go quite a long way.  Similarly but 
from a different angle, if Zac says that he's not satisfied with the 
specification even with portage's already implementing what's there and 
having it proven to work (for whatever definition of "work"), that goes 
quite a way toward giving the argument for a better spec some serious 
support, as well.


If you can't get those statements, then round and round the discussion 
will go until people are sick, and until people simply ignore your 
position and push /something/ thru, which would be a real shame if it 
could be practically[1] made better, or the practical ideal of PMS ends 
up getting lost in the results.

And if you /can/ get those statements, why are we still going round and 
round with all this?  (Again, references to said statements may be 
necessary from time to time, given the quantity of posts and the 
likelihood single answers in support of your position could be missed.)


[1] Practically: favorable cost/benefit ratio for the work needed.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: My wishlist for EAPI 5

[Duncan]

Duncan posted on Sat, 23 Jun 2012 10:37:38 +0000 as excerpted:

> Ciaran McCreesh posted on Sat, 23 Jun 2012 10:38:33 +0100 as excerpted:
> 
> 
> 3) Given the above, it would be of /great/ benefit to your argument if
> either Zac or Brian (or preferably both) stepped up from time to time
> and said yes, this is really an issue.
> 
> Not that they'd necessarily reply to everything you do, but if they
> could reply once in support, such that you could refer people back to
> those replies from elsewhere...

Right after posting that, I saw you mentioned the link below.  Thanks.
That's exactly the sort of thing I think a lot of readers (myself
included) could use a bit more of, reminding us it's not just you.


http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Sat, 23 Jun 2012 10:37:38 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> 1) Fact: Unfortunately, your method of argument, Ciaran, doesn't
> endear you to a number of devs.  Some may have the impulse to reject
> an argument simply because it comes from you.

Perhaps Gentoo should be doing more to correct the attitudes of those
developers, then.

> 2) PMS is supposed to be about specifying things well enough that all 
> three PMs can implement compatible ebuild/eclass/etc interpretation
> and execution.

Not exactly. It's about making sure ebuild developers know what they
can rely upon from a package mangler.

> 3) Given the above, it would be of /great/ benefit to your argument
> if either Zac or Brian (or preferably both) stepped up from time to
> time and said yes, this is really an issue.

They already have. For example:

http://archives.gentoo.org/gentoo-dev/msg_86b67d8ab51a24922a3d3be75d10f42b.xml

> And if you /can/ get those statements, why are we still going round
> and round with all this?

That's a very good question. Why are people still blaming the PMS team
for the lack of magical appearance of flying unicorns rather than
making their case for the introduction of a horse?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: My wishlist for EAPI 5

[Rich Freeman]

On Sat, Jun 23, 2012 at 6:44 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 10:37:38 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>> 1) Fact: Unfortunately, your method of argument, Ciaran, doesn't
>> endear you to a number of devs.  Some may have the impulse to reject
>> an argument simply because it comes from you.
>
> Perhaps Gentoo should be doing more to correct the attitudes of those
> developers, then.
>

This is an impression that many people get, unfortunately.  You can't
fix it by beating people up.  There are those who speak up from time
to time attempting to moderate, although to some extent this is noise
in what should be a technical discussion.

>
>> And if you /can/ get those statements, why are we still going round
>> and round with all this?
>
> That's a very good question. Why are people still blaming the PMS team
> for the lack of magical appearance of flying unicorns rather than
> making their case for the introduction of a horse?
>

Perhaps what is being missed is that THIS ISN'T A WATERFALL METHODOLOGY!!!

PMS is intended to be semi-retrospective - it is developed in parallel
with the features it documents.  It is intended to preserve standards,
to be something to refer to before finalizing PM code, and to guide
ebuild writers.  It isn't intended to be a conceptual
requirements/design spec to be included in the RFP for the coding team
in India.

So, the requirement is a reference implementation in one of the PMs.
So, the question of "who gets to decide it is easy" is simple -
whoever writes and releases the patch gets to decide.  That can be you
if you write a full PM that handles all the existing EAPIs plus
whatever is new, or demonstrate some kind of commitment to maintaining
a fork.

Face it, there are only a handful of devs here doing PM work, portage
or otherwise.  I can post all day on the list about how Gentoo OUGHT
to be able to do foo.  I can post all day about how Gentoo NEEDS to do
foo and how it is downright obvious how not doing foo ruins the
reputation of Gentoo and is going to kill us in six months.  None of
this is going to do anything unless I can convince/bribe/cajole one of
the devs working on a PM to implement foo, or, heaven-forbid, write it
myself.

Somebody asked earlier why Cirian is running the whole PMS process and
why Gentoo can't have its own GEAPI that will be peaceful and
harmonious.  My answers to that are twofold:

1.  While perhaps a different leader might give people a warmer
feeling about it, I think many of these issues are just inherent to
the nature of the problem - PM features don't write themselves.
Others might disagree, and that is fine.

2.  I don't see anybody else stepping up.  PMS is in git, so just
clone the thing and if you can convince some PM devs to follow you
there is no reason that a Gentoo dev couldn't take it over.  I suspect
that many would like to see this happen.  However, to be honest I
think that warm-and-fuzzies aside Cirian has actually done a fairly
good job with it as he is pretty passionate about PM specs.  This is a
big commitment, and what isn't needed is somebody who is going to step
in to get their favorite feature in there and then let it die.

As far as helping others to create pms paperwork goes, there is no
reason this has to fall exclusively on Cirian.  The fact that nobody
else is stepping up to help those who are new just reflects the nature
of something like this - FOSS projects tend to be weak on specs.

Bottom line - do I think Cirian might get himself further in life if
he deals with others a bit differently?  Sure.  Do I think that this
is the main thing keeping us outside of the golden land of PMS?  Not
really.

Rich

[gentoo-dev] Re: My wishlist for EAPI 5

[Duncan]

Rich Freeman posted on Sat, 23 Jun 2012 07:12:29 -0400 as excerpted:

> You can't fix it by beating people up.

Volunteers do it on their own terms... or don't do it.  The outliers can 
be moderated to some degree and thankfully the list isn't what it once 
was, but get too strict and people simply find other things to do.  Of 
course there's a line where letting them find something else to do is 
best, and some have crossed it, but...

> 1.  While perhaps a different leader might give people a warmer feeling
> about it, I think many of these issues are just inherent to the nature
> of the problem - PM features don't write themselves.  Others might
> disagree, and that is fine.
> 
> 2.  I don't see anybody else stepping up.

Good points.  (Whole post actually, but snipped for brevity.)  To some 
extent, the job of coordinating PMS is going to be a (nearly) thankless 
task, and it does take a specific kind of person to keep at it.  Not 
everybody's cut out for it.  You're right, others /aren't/ stepping up 
for it and I can't blame them.  Thanks for pointing out what we likely 
all knew if we thought about it, but many (me included) sometimes forget.


Back to my original point, tho.  Seeing people working on other PMs make 
the point as well, helps, and I hope to see both a bit more of that and 
more reminders of it in other subthreads/replies, where appropriate.  I 
know that helps me keep a bit better perspective. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] My wishlist for EAPI 5

[Alec Warner]

On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
>> On Thu, 21 Jun 2012 08:08:55 +0200
>> Pacho Ramos <pacho@gentoo.org> wrote:
>> > Also, if I remember correctly, Tommy asked for this some months ago,
>> > you asked for what he sent some days ago and now you require more and
>> > more work to delay things to be implemented.
>>
>> I still haven't seen a clear description of exactly what should be
>> changed and why. I've also not seen a description of exactly what
>> problem is being solved, nor a discussion of the relative merits of
>> implementing a solution to whatever that problem is. All I've seen is a
>> mess of code that "gets it working" in Portage (which isn't the same as
>> "implements it for Portage") and a big wall of text that contains lots
>> that no-one needs to know and little of what's important. This needs to
>> go through the GLEP process, and it needs a PMS diff.
>>
>> In case you're not aware, the first time Gentoo did multilib, it was
>> done as a series of random changes to Portage that no-one really
>> thought through or understood. As you can see, that didn't work...
>>
>
> Then, looks clear to me that the way to get things approved in newer
> EAPIs is not clear enough as looks like a lot of devs (like me) don't
> know them (for example, when things to be added to EAPI need also a GLEP
> and a PMS diff, also the needing to get an implementation for any
> package manager). Is this documented in some place? If not, I think it
> should be documented and, of course, it should be done by PMS team if
> possible as they clearly know what they expect to get for approval if
> needed since, I discussed some days ago, council will simply accept some
> specific features to be included in next eapi once they are accepted by
> PMS team. That way, we could save a lot of time, know what steps are
> pending, try to ask for help for some specific steps and, finally, get
> it discussed in PMS people providing all what is needed.
>
>
>> > I also don't understand why Gentoo is forced to stick with old ways
>> > of doing things until new EAPI is approved
>>
>> That's not what's going on here. The issue is that there might be one
>> person who understands what "the new way of doing things", but he
>> hasn't told us what he thinks that is. Once we get a proper
>> explanation, getting an EAPI out doesn't take long.
>>
>
> But you must confess that old problems like multilib support, force
> package rebuilding or optional dep support are still pending while still
> needing and, the problem with the way things are discussed now is that
> some day anybody arises the problem again, other one demands more things
> to be provided, a discussion starts, the problem gets stalled... one
> year later the same problem arises again. There is clearly a lack of
> information to the rest of developers about how to propose anything to
> get accepted for next EAPI.

I'm not following you here.

1) Usually features need a reference implementation.
2) For portage, there are like 3-5 people who know portage well enough
to write that for you.
3) You generally have to convince them to do it before you can move forward.
4) Most features never even get a reference implementation.

There is this vague idea that you can just propose something; get
consensus on the ML, everyone goes to implement it, and then it works
just as designed. That is usually called the 'waterfall' model and its
really hard to do correctly.

What I imagine the process is:

1) Submit an idea to the ML; you just need feedback (not consensus,
which is likely impossible for non-trivial ideas.)
  1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required.
2) Take feedback from step one and make an initial implementation. You
will likely find some assumptions in your 'design' from step one were
wrong, as well as other implementation issues (UI, performance, etc.)
3) Modify your idea to address the problems in 2.
4) Modify your implementation to address the problems in 2.
5) Repeat steps 2-4 a few times until you have solved all the 'big' problems.
6) Submit a diff to PMS outlining how the package manager behavior is
changed by your feature. This generally needs to be specific enough so
that other package manager authors can implement the feature.
7) Submit a devmanual patch telling users how to use the feature.

Most people fail at step two; usually because they try to get
'consensus' at step one, which is stupid and a waste of time. There
are a few hundred people on this list; we will never all agree, on
basically anything. So take the feedback people give you and do
something with it.

>
>> The main problem here isn't even EAPI related. Ebuild developers don't
>> even know what they'll be expected, required or able to do for multilib.
>>
>> > while Exherbo is free to implement and use things like that special
>> > way of handling DEPENDENCIES without waiting for any EAPI to be
>> > accepted...
>>
>> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
>> have it because Portage couldn't implement it. Now it doesn't have it
>> because it's too controversial to get it approved.
>
> It was only a example, but thanks for the info :)
>
>> Exherbo does have it
>> because it was carefully discussed, compared to alternatives, planned
>> out, tested, accepted by the expendable figurehead, and then rolled out.
>>
>> > or maybe I am wrong and people is able to use any PM manager
>> > compliant with EAPI on exherbo without issues?
>>
>> If anyone ever manages to come up with another package mangler that can
>> get close to implementing what Exherbo needs, then sure.
>>
>
> Then, you accept exherbo is not forced to *only* follow EAPI while you
> force Gentoo and portage to only support features approved in an EAPI?
>

Portage can use whatever EAPIs portage wishes to publish (Zac has
published portage specific EAPIs in the past.) Generally in gentoo-x86
you can only use council approved EAPIs; so if portage was to publish
something like 'portage-1' you would have to get council approval to
use it in Gentoo-x86. It seems like a reasonable request to me, why
not talk to them about it.

The reason exherbo can 'do whatever they want' is because the project
is marketed that way. Seriously, go to Exherbo.org and look at the
'Why' section. Reason 2 is 'we need to break stuff whenever we feel it
is beneficial.' Gentoo is not marketed that way to our users. We
'generally promise' backwards compat for 6-12 months.

If we randomly added stuff to portage without being bound by EAPI then
we end up breaking stuff unintentionally all the time when rolling out
features.

-A

Re: [gentoo-dev] My wishlist for EAPI 5

[Rich Freeman]

On Thu, Jun 21, 2012 at 5:27 AM, Alec Warner <antarus@gentoo.org> wrote:
> There is this vague idea that you can just propose something; get
> consensus on the ML, everyone goes to implement it, and then it works
> just as designed. That is usually called the 'waterfall' model and its
> really hard to do correctly.
>

++

Waterfall has problems even in places where people are paid to do
work.  It has little chance of working here.

Devs aren't paid to do work.  They do what interests them.  So, the
most effective way to make something happen is to do it yourself, or
better still make it something interesting, do it yourself, and
inspire others to help you out.  A working program will always gather
more interest than a discussion on a list.

Plus Gentoo is all about choice - even if it never becomes the
standard lots of people will do it anyway.  Look at paludis, systemd,
and so on.  The autobuilt releases started out as drobbins side
project on funtoo before they became the mainstream Gentoo way.
Showing people that something works is always better than telling
them.

Rich

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El jue, 21-06-2012 a las 11:27 +0200, Alec Warner escribió:
> On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> >> On Thu, 21 Jun 2012 08:08:55 +0200
> >> Pacho Ramos <pacho@gentoo.org> wrote:
> >> > Also, if I remember correctly, Tommy asked for this some months ago,
> >> > you asked for what he sent some days ago and now you require more and
> >> > more work to delay things to be implemented.
> >>
> >> I still haven't seen a clear description of exactly what should be
> >> changed and why. I've also not seen a description of exactly what
> >> problem is being solved, nor a discussion of the relative merits of
> >> implementing a solution to whatever that problem is. All I've seen is a
> >> mess of code that "gets it working" in Portage (which isn't the same as
> >> "implements it for Portage") and a big wall of text that contains lots
> >> that no-one needs to know and little of what's important. This needs to
> >> go through the GLEP process, and it needs a PMS diff.
> >>
> >> In case you're not aware, the first time Gentoo did multilib, it was
> >> done as a series of random changes to Portage that no-one really
> >> thought through or understood. As you can see, that didn't work...
> >>
> >
> > Then, looks clear to me that the way to get things approved in newer
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't
> > know them (for example, when things to be added to EAPI need also a GLEP
> > and a PMS diff, also the needing to get an implementation for any
> > package manager). Is this documented in some place? If not, I think it
> > should be documented and, of course, it should be done by PMS team if
> > possible as they clearly know what they expect to get for approval if
> > needed since, I discussed some days ago, council will simply accept some
> > specific features to be included in next eapi once they are accepted by
> > PMS team. That way, we could save a lot of time, know what steps are
> > pending, try to ask for help for some specific steps and, finally, get
> > it discussed in PMS people providing all what is needed.
> >
> >
> >> > I also don't understand why Gentoo is forced to stick with old ways
> >> > of doing things until new EAPI is approved
> >>
> >> That's not what's going on here. The issue is that there might be one
> >> person who understands what "the new way of doing things", but he
> >> hasn't told us what he thinks that is. Once we get a proper
> >> explanation, getting an EAPI out doesn't take long.
> >>
> >
> > But you must confess that old problems like multilib support, force
> > package rebuilding or optional dep support are still pending while still
> > needing and, the problem with the way things are discussed now is that
> > some day anybody arises the problem again, other one demands more things
> > to be provided, a discussion starts, the problem gets stalled... one
> > year later the same problem arises again. There is clearly a lack of
> > information to the rest of developers about how to propose anything to
> > get accepted for next EAPI.
> 
> I'm not following you here.
> 
> 1) Usually features need a reference implementation.
> 2) For portage, there are like 3-5 people who know portage well enough
> to write that for you.
> 3) You generally have to convince them to do it before you can move forward.
> 4) Most features never even get a reference implementation.
> 
> There is this vague idea that you can just propose something; get
> consensus on the ML, everyone goes to implement it, and then it works
> just as designed. That is usually called the 'waterfall' model and its
> really hard to do correctly.
> 
> What I imagine the process is:
> 
> 1) Submit an idea to the ML; you just need feedback (not consensus,
> which is likely impossible for non-trivial ideas.)
>   1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required.
> 2) Take feedback from step one and make an initial implementation. You
> will likely find some assumptions in your 'design' from step one were
> wrong, as well as other implementation issues (UI, performance, etc.)
> 3) Modify your idea to address the problems in 2.
> 4) Modify your implementation to address the problems in 2.
> 5) Repeat steps 2-4 a few times until you have solved all the 'big' problems.
> 6) Submit a diff to PMS outlining how the package manager behavior is
> changed by your feature. This generally needs to be specific enough so
> that other package manager authors can implement the feature.
> 7) Submit a devmanual patch telling users how to use the feature.
> 
> Most people fail at step two; usually because they try to get
> 'consensus' at step one, which is stupid and a waste of time. There
> are a few hundred people on this list; we will never all agree, on
> basically anything. So take the feedback people give you and do
> something with it.
> 

OK thanks :) What I was trying to show is that this process is not clear
enough, you even need to say that you "imagine" that it's the process,
and looks pretty reasonable but, if that process is kept undocumented,
we are doomed to revive the problem again and again

About trying to get a consensus, I think it's wanted to not waste time
reimplementing things a lot of times. Think for example in ABI_SLOT
stuff, we reached some small consensus about, at least, use SLOT/SUBSLOT
approach, that will probably save a bit of time to people making the
implementation as he won't need to firstly implemente ABI_SLOT way,
later get it rejected again and, finally, re-implement it with
SLOT/SUBSLOT. The idea is to try to help people doing the huge work of
getting the implementation to save as much time as possible.

But I also understand your point as looks like usually it's really
difficult to reach consensus :/

> >
> >> The main problem here isn't even EAPI related. Ebuild developers don't
> >> even know what they'll be expected, required or able to do for multilib.
> >>
> >> > while Exherbo is free to implement and use things like that special
> >> > way of handling DEPENDENCIES without waiting for any EAPI to be
> >> > accepted...
> >>
> >> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't
> >> have it because Portage couldn't implement it. Now it doesn't have it
> >> because it's too controversial to get it approved.
> >
> > It was only a example, but thanks for the info :)
> >
> >> Exherbo does have it
> >> because it was carefully discussed, compared to alternatives, planned
> >> out, tested, accepted by the expendable figurehead, and then rolled out.
> >>
> >> > or maybe I am wrong and people is able to use any PM manager
> >> > compliant with EAPI on exherbo without issues?
> >>
> >> If anyone ever manages to come up with another package mangler that can
> >> get close to implementing what Exherbo needs, then sure.
> >>
> >
> > Then, you accept exherbo is not forced to *only* follow EAPI while you
> > force Gentoo and portage to only support features approved in an EAPI?
> >
> 
> Portage can use whatever EAPIs portage wishes to publish (Zac has
> published portage specific EAPIs in the past.) Generally in gentoo-x86
> you can only use council approved EAPIs; so if portage was to publish
> something like 'portage-1' you would have to get council approval to
> use it in Gentoo-x86. It seems like a reasonable request to me, why
> not talk to them about it.

Didn't know that it was allowed. Thanks a lot for the information :)

> 
> The reason exherbo can 'do whatever they want' is because the project
> is marketed that way. Seriously, go to Exherbo.org and look at the
> 'Why' section. Reason 2 is 'we need to break stuff whenever we feel it
> is beneficial.' Gentoo is not marketed that way to our users. We
> 'generally promise' backwards compat for 6-12 months.
> 
> If we randomly added stuff to portage without being bound by EAPI then
> we end up breaking stuff unintentionally all the time when rolling out
> features.
> 
> -A
> 
> 

Well, I was more thinking on having our own "EAPIs", but I see I didn't
explain it properly in previous mail, sorry

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Patrick Lauer]

On 06/21/12 15:25, Pacho Ramos wrote:
> El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
>> On Thu, 21 Jun 2012 08:08:55 +0200
>> Pacho Ramos <pacho@gentoo.org> wrote:
>>> Also, if I remember correctly, Tommy asked for this some months ago,
>>> you asked for what he sent some days ago and now you require more and
>>> more work to delay things to be implemented.
>> I still haven't seen a clear description of exactly what should be
>> changed and why. I've also not seen a description of exactly what
>> problem is being solved, nor a discussion of the relative merits of
>> implementing a solution to whatever that problem is. All I've seen is a
>> mess of code that "gets it working" in Portage (which isn't the same as
>> "implements it for Portage") and a big wall of text that contains lots
>> that no-one needs to know and little of what's important. This needs to
>> go through the GLEP process, and it needs a PMS diff.
>>
>> In case you're not aware, the first time Gentoo did multilib, it was
>> done as a series of random changes to Portage that no-one really
>> thought through or understood. As you can see, that didn't work...
>>
> Then, looks clear to me that the way to get things approved in newer
> EAPIs is not clear enough as looks like a lot of devs (like me) don't
> know them (for example, when things to be added to EAPI need also a GLEP
> and a PMS diff, also the needing to get an implementation for any
> package manager). Is this documented in some place?
No, and this is a rather random ad-hoc requirement that hasn't been
specified before.

All previous EAPI processes went through some debate with dev-portage@
and the other involved people (mostly pkgcore/ferringb and
paludis/ciaranm), then the proposal got handed to council to vote on,
and if council was happy that proposal was hammered into PMS and the new
EAPI published. Most of the time new features had a crude approximation
of a patch for PMS available so that the documentation updates were done
in a timely manner.

I have no idea why Ciaran is trying to redefine the process now suddenly
and why people are taking this nonsense seriously.

>  If not, I think it
> should be documented and, of course, it should be done by PMS team if
> possible as they clearly know what they expect to get for approval if
> needed since, I discussed some days ago, council will simply accept some
> specific features to be included in next eapi once they are accepted by
> PMS team. That way, we could save a lot of time, know what steps are
> pending, try to ask for help for some specific steps and, finally, get
> it discussed in PMS people providing all what is needed.
I would say PMS team accepts what council signs off ... or am I seeing
the order wrong here?


So, the normal way to get a feature into the next EAPI is ... write a
specification to the best of your capabilities, present it here, when
people are done bashing it ask PMS people to help you prepare a PMS
patch so that you can suggest it to Council, and then it's mostly a
matter of waiting until the next EAPI is finalized (which currently runs
at a glacial pace of about one EAPI a year as far as I remember)


Take care,

Patrick

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Thu, 21 Jun 2012 19:15:02 +0800
Patrick Lauer <patrick@gentoo.org> wrote:
> > Then, looks clear to me that the way to get things approved in newer
> > EAPIs is not clear enough as looks like a lot of devs (like me)
> > don't know them (for example, when things to be added to EAPI need
> > also a GLEP and a PMS diff, also the needing to get an
> > implementation for any package manager). Is this documented in some
> > place?
> No, and this is a rather random ad-hoc requirement that hasn't been
> specified before.

It's dependent upon the level of complexity of the work, and whether or
not anyone on the PMS team understands it enough to be able to do the
work themselves. As far as I know, none of us do on this one, so it's
down to whoever wants it to educate us enough that we can get it done...

> All previous EAPI processes went through some debate with dev-portage@
> and the other involved people (mostly pkgcore/ferringb and
> paludis/ciaranm), then the proposal got handed to council to vote on,
> and if council was happy that proposal was hammered into PMS and the
> new EAPI published. Most of the time new features had a crude
> approximation of a patch for PMS available so that the documentation
> updates were done in a timely manner.

Actually, we've been passing pretty much final PMS patches to the
Council to vote on. 

> I have no idea why Ciaran is trying to redefine the process now
> suddenly and why people are taking this nonsense seriously.

I'm not.

> I would say PMS team accepts what council signs off ... or am I seeing
> the order wrong here?

The PMS team makes suggestions to the Council, and the Council accepts
a subset of those. The Council can also suggest that the PMS team looks
at a particular feature, but as Gentoo has no mechanism in place for
forcing work to get done, that only works if there's someone with both
the time and the knowledge to figure it out.

> So, the normal way to get a feature into the next EAPI is ... write a
> specification to the best of your capabilities, present it here, when
> people are done bashing it ask PMS people to help you prepare a PMS
> patch so that you can suggest it to Council

Yup, and for difficult cases like the ones under discussion, a part of
presenting it is to demo a working implementation on real packages so
that we gain real world experience of the feature.

It's also important to note that "the best of your capabilities" may
not be anywhere near enough for the PMS people or the package mangler
people to do the remainder of the work.

> and then it's mostly a
> matter of waiting until the next EAPI is finalized (which currently
> runs at a glacial pace of about one EAPI a year as far as I remember)

I like how you simultaneously troll both sides of that issue. Weren't
you previously claiming there were too many EAPIs and that we shouldn't
have lots of new ones?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Pacho Ramos]

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

El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió:
> On 06/21/12 15:25, Pacho Ramos wrote:
> > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió:
> >> On Thu, 21 Jun 2012 08:08:55 +0200
> >> Pacho Ramos <pacho@gentoo.org> wrote:
> >>> Also, if I remember correctly, Tommy asked for this some months ago,
> >>> you asked for what he sent some days ago and now you require more and
> >>> more work to delay things to be implemented.
> >> I still haven't seen a clear description of exactly what should be
> >> changed and why. I've also not seen a description of exactly what
> >> problem is being solved, nor a discussion of the relative merits of
> >> implementing a solution to whatever that problem is. All I've seen is a
> >> mess of code that "gets it working" in Portage (which isn't the same as
> >> "implements it for Portage") and a big wall of text that contains lots
> >> that no-one needs to know and little of what's important. This needs to
> >> go through the GLEP process, and it needs a PMS diff.
> >>
> >> In case you're not aware, the first time Gentoo did multilib, it was
> >> done as a series of random changes to Portage that no-one really
> >> thought through or understood. As you can see, that didn't work...
> >>
> > Then, looks clear to me that the way to get things approved in newer
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't
> > know them (for example, when things to be added to EAPI need also a GLEP
> > and a PMS diff, also the needing to get an implementation for any
> > package manager). Is this documented in some place?
> No, and this is a rather random ad-hoc requirement that hasn't been
> specified before.
> 
> All previous EAPI processes went through some debate with dev-portage@
> and the other involved people (mostly pkgcore/ferringb and
> paludis/ciaranm), then the proposal got handed to council to vote on,
> and if council was happy that proposal was hammered into PMS and the new
> EAPI published. Most of the time new features had a crude approximation
> of a patch for PMS available so that the documentation updates were done
> in a timely manner.
> 
> I have no idea why Ciaran is trying to redefine the process now suddenly
> and why people are taking this nonsense seriously.

I take it seriously because looks like, effectively, this is blocking
things. I remember when I first asked for an "easy" way of trying to
allow administrator of Gentoo machines to easily handling all that
needed rebuilds after updating:
https://bugs.gentoo.org/show_bug.cgi?id=413619

Zac kindly pointed me to original bug:
https://bugs.gentoo.org/show_bug.cgi?id=192319

I knew about that bug report but, as it was still pending after years, I
thought there were technical issues making it hard to fix and, then, I
tried to propose and easier solution at least until best one can be
implemented. Then, if you remember the thread I opened here some weeks
ago about this issue, you will see how things moved, even when Zac is
already working on getting an implementation I am really worried about,
even after Zac offering his work and time to get an implementation, when
he offers it, Ciaran will reject it with some other excuse :(

> 
> >  If not, I think it
> > should be documented and, of course, it should be done by PMS team if
> > possible as they clearly know what they expect to get for approval if
> > needed since, I discussed some days ago, council will simply accept some
> > specific features to be included in next eapi once they are accepted by
> > PMS team. That way, we could save a lot of time, know what steps are
> > pending, try to ask for help for some specific steps and, finally, get
> > it discussed in PMS people providing all what is needed.
> I would say PMS team accepts what council signs off ... or am I seeing
> the order wrong here?
> 
> 
> So, the normal way to get a feature into the next EAPI is ... write a
> specification to the best of your capabilities, present it here, when
> people are done bashing it ask PMS people to help you prepare a PMS
> patch so that you can suggest it to Council, and then it's mostly a
> matter of waiting until the next EAPI is finalized (which currently runs
> at a glacial pace of about one EAPI a year as far as I remember)
> 
> 
> Take care,
> 
> Patrick
> 
> 



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

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

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

On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> 
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work... 

	No, but paved the way for other distros as they had nothing even close.
I'm sure you remember back then. Don't be an ass.

-- 
Homer Parker <hparker@gentoo.org>

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Thu, 21 Jun 2012 07:11:27 -0500
Homer Parker <hparker@gentoo.org> wrote:
> On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > In case you're not aware, the first time Gentoo did multilib, it was
> > done as a series of random changes to Portage that no-one really
> > thought through or understood. As you can see, that didn't work... 
> 
> 	No, but paved the way for other distros as they had nothing
> even close. I'm sure you remember back then. Don't be an ass.

And what did Gentoo get out of it?

What I remember is Gentoo putting in lots of work randomly changing
things until things worked, and ending up not knowing what most of
those changes were or why they were done. The end result is that
there's still a random smattering of multilib-related mess cluttering
up ebuild internals that doesn't actually do anything except cause
intermittent breakages. Doing experiments is great as a way of
understanding the problem, but it isn't how you deliver a solution.
That takes a lot more work, and someone has to be prepared to do it.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

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

On Thu, 2012-06-21 at 13:30 +0100, Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 07:11:27 -0500
> Homer Parker <hparker@gentoo.org> wrote:
> > On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > > In case you're not aware, the first time Gentoo did multilib, it was
> > > done as a series of random changes to Portage that no-one really
> > > thought through or understood. As you can see, that didn't work... 
> > 
> > 	No, but paved the way for other distros as they had nothing
> > even close. I'm sure you remember back then. Don't be an ass.
> 
> And what did Gentoo get out of it?
> 
> What I remember is Gentoo putting in lots of work randomly changing
> things until things worked, and ending up not knowing what most of
> those changes were or why they were done. The end result is that
> there's still a random smattering of multilib-related mess cluttering
> up ebuild internals that doesn't actually do anything except cause
> intermittent breakages. Doing experiments is great as a way of
> understanding the problem, but it isn't how you deliver a solution.
> That takes a lot more work, and someone has to be prepared to do it.
> 

	The hell? Other distos where still thinking of how to implement
multilib and we had it. I know first hand as I trashed a system trying
out the latest-n-greatest.. And the next round fixed it. The -emul
packages from then on along with the multilib profiles have worked fine.
Again, quit being an ass. Oh, and what I remember is.. You didn't
contribute. There was kingtaco, lv, and kuglafang <sp?>. So you're clear
there, you didn't have a damn thing to do with it.

-- 
Homer Parker <hparker@gentoo.org>

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Thu, 21 Jun 2012 08:13:50 -0500
Homer Parker <hparker@gentoo.org> wrote:
> > And what did Gentoo get out of it?
> > 
> > What I remember is Gentoo putting in lots of work randomly changing
> > things until things worked, and ending up not knowing what most of
> > those changes were or why they were done. The end result is that
> > there's still a random smattering of multilib-related mess
> > cluttering up ebuild internals that doesn't actually do anything
> > except cause intermittent breakages. Doing experiments is great as
> > a way of understanding the problem, but it isn't how you deliver a
> > solution. That takes a lot more work, and someone has to be
> > prepared to do it.
> 
> 	The hell? Other distos where still thinking of how to
> implement multilib and we had it. I know first hand as I trashed a
> system trying out the latest-n-greatest.. And the next round fixed
> it. The -emul packages from then on along with the multilib profiles
> have worked fine.

...so why are people running around demanding that reinventing multilib
is the number one priority and has to be in EAPI 5 immediately then? I
was under the impression that your fellow developers don't consider the
-emul packages to be an adequate solution. If that isn't the case, and
the existing mechanism is in fact fine as you claim, then great, we can
ignore multilib from an EAPI perspective.

I can only go on what your colleagues are claiming here. I suggest if
you're upset at the suggestion that Gentoo doesn't have a decent
multilib implementation then you take it up with all the people who are
demanding the PMS team provide them with one.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

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

On Thu, 2012-06-21 at 14:20 +0100, Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 08:13:50 -0500
> Homer Parker <hparker@gentoo.org> wrote:
> > > And what did Gentoo get out of it?
> > > 
> > > What I remember is Gentoo putting in lots of work randomly changing
> > > things until things worked, and ending up not knowing what most of
> > > those changes were or why they were done. 

	In the beginning there was a method...

> The end result is that
> > > there's still a random smattering of multilib-related mess
> > > cluttering up ebuild internals that doesn't actually do anything
> > > except cause intermittent breakages. Doing experiments is great as
> > > a way of understanding the problem, but it isn't how you deliver a
> > > solution. That takes a lot more work, and someone has to be
> > > prepared to do it.
> > 
> > 	The hell? Other distos where still thinking of how to
> > implement multilib and we had it. I know first hand as I trashed a
> > system trying out the latest-n-greatest.. And the next round fixed
> > it. The -emul packages from then on along with the multilib profiles
> > have worked fine.
> 
> ...so why are people running around demanding that reinventing multilib
> is the number one priority and has to be in EAPI 5 immediately then? I
> was under the impression that your fellow developers don't consider the
> -emul packages to be an adequate solution. If that isn't the case, and
> the existing mechanism is in fact fine as you claim, then great, we can
> ignore multilib from an EAPI perspective.

	And now it needs revamped.. I see no problem with re-investigating the
problem to make it better/easier/whatever.

> I can only go on what your colleagues are claiming here. I suggest if
> you're upset at the suggestion that Gentoo doesn't have a decent
> multilib implementation then you take it up with all the people who are
> demanding the PMS team provide them with one.
> 

	I can only suggest you keep track of your train of thought.. In the
beginning vs now are two completely separate issues. We were first, is
it surprising the method needs looked at? No.


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

Re: [gentoo-dev] My wishlist for EAPI 5

[Rich Freeman]

On Thu, Jun 21, 2012 at 4:26 PM, Homer Parker <hparker@gentoo.org> wrote:
>
>        In the beginning there was a method...
>
>        And now it needs revamped.. I see no problem with re-investigating the
> problem to make it better/easier/whatever.
>

++

I for one am happy to have had a working amd64 system for the last
decade, even if it might have been somewhat better if I had been stuck
on 32-bit while the perfect system was devised.

Gentoo doesn't need thrown-together hacks, but half-decent solutions
that work shouldn't be held up in favor of ideal solutions that don't
exist.  There is always room for evolution.

That said, as far as EAPIs go I'm in favor of shipping whatever is
ready to ship.

Rich

Re: [gentoo-dev] My wishlist for EAPI 5

[Mike Frysinger]

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

On Thursday 21 June 2012 08:11:27 Homer Parker wrote:
> On Thu, 2012-06-21 at 08:00 +0100, Ciaran McCreesh wrote:
> > In case you're not aware, the first time Gentoo did multilib, it was
> > done as a series of random changes to Portage that no-one really
> > thought through or understood. As you can see, that didn't work...
> 
> 	No, but paved the way for other distros as they had nothing even close.
> I'm sure you remember back then. Don't be an ass.

many distros still don't.  ever try Debian on ppc64 ? :)
-mike

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Mike Frysinger]

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

On Thursday 21 June 2012 03:00:39 Ciaran McCreesh wrote:
> In case you're not aware, the first time Gentoo did multilib, it was
> done as a series of random changes to Portage that no-one really
> thought through or understood. As you can see, that didn't work...

yes yes, it's very easy to throw rocks in hindsight at developers who, quite 
literally, were in completely new waters.  not just in the Gentoo/PMS world, 
but in multilib *anywhere* (other distros, upstream packages, etc...).  i'd 
say it's almost as easy as shooting fish in a barrel, but mythbusters proved 
that's actually kind of hard.
-mike

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Wed, 20 Jun 2012 23:43:36 +0200
Justin <jlec@gentoo.org> wrote:
> On 20.06.2012 22:35, Ciaran McCreesh wrote:
> > On Wed, 20 Jun 2012 16:25:30 -0400
> > Richard Yao <ryao@gentoo.org> wrote:
> >> Multilib (and/or multiarch) support
> >> 	The current binaries cause a great deal of pain,
> >> particularly when a user does not want to upgrade something. I had
> >> this problem with WINE and glibc because I wanted to avoid the
> >> reverse memcpy() fiasco on my systems. This situation would have
> >> been avoided entirely if the package manager supported multilib.
> > 
> > This one's unlikely to happen unless someone's prepared to put in
> > the work.
> 
> Tommy worked a lot on this and he asked for help to bring his
> proposal/spec/glep into shape.
> We are all aware what this is all about and know that anybody who is
> using multilib would benefit.
> Can't you simply work with him together to get it into what you expect
> it to be instead of pointing out that it isn't?

In order to do that, it would have to get to the stage where I
understood exactly what changes are needed and why. I'm not convinced
*anyone* understands that yet.

Writing PMS patches, at least to the level that we can review them, is
only difficult if you don't know what you want changed or why.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[justin]

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

On 21/06/12 08:41, Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 23:43:36 +0200
> Justin <jlec@gentoo.org> wrote:
>> On 20.06.2012 22:35, Ciaran McCreesh wrote:
>>> On Wed, 20 Jun 2012 16:25:30 -0400
>>> Richard Yao <ryao@gentoo.org> wrote:
>>>> Multilib (and/or multiarch) support
>>>> 	The current binaries cause a great deal of pain,
>>>> particularly when a user does not want to upgrade something. I had
>>>> this problem with WINE and glibc because I wanted to avoid the
>>>> reverse memcpy() fiasco on my systems. This situation would have
>>>> been avoided entirely if the package manager supported multilib.
>>>
>>> This one's unlikely to happen unless someone's prepared to put in
>>> the work.
>>
>> Tommy worked a lot on this and he asked for help to bring his
>> proposal/spec/glep into shape.
>> We are all aware what this is all about and know that anybody who is
>> using multilib would benefit.
>> Can't you simply work with him together to get it into what you expect
>> it to be instead of pointing out that it isn't?
> 
> In order to do that, it would have to get to the stage where I
> understood exactly what changes are needed and why. I'm not convinced
> *anyone* understands that yet.
> 
> Writing PMS patches, at least to the level that we can review them, is
> only difficult if you don't know what you want changed or why.
> 

He wants to deprecate the app-emulation/emul-linux-x86-* packages and
build it if needed directly from "normal" ebuilds through the package
manager. This was stated a couple of times and is not hard to
understand, even without PMS patches, GLEPS and so.

*anyone* understands that there are cases when the x86 libs are needed
and every gentoo package maintainer should understand, that letting the
user build their own x86 libs is what we want in ideal case.

There is a working implementation as a branch of portage for some time
now and people work on it.

So two basic things are there, the need and the idea of a working
solution. This also means, that people need to have an idea of what is
real problem. (And if not, it was asked a couple of times for discussion)

Won't it be a good thing, if you instead of showing all of us, that you
can tell where people fail to present something in the right way, help
and guide them to write the necessary things like PMS patches, GLEPs
etc., so that we can proceed in an efficient way?

justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

Re: [gentoo-dev] My wishlist for EAPI 5

[Homer Parker]

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

On Thu, 2012-06-21 at 09:24 +0200, justin wrote:
> Won't it be a good thing, if you instead of showing all of us, that
> you
> can tell where people fail to present something in the right way, help
> and guide them to write the necessary things like PMS patches, GLEPs
> etc., so that we can proceed in an efficient way? 

	That's not his style. Never has been, and I don't see that changing.

-- 
Homer Parker <hparker@gentoo.org>

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Thu, 21 Jun 2012 07:14:49 -0500
Homer Parker <hparker@gentoo.org> wrote:
> On Thu, 2012-06-21 at 09:24 +0200, justin wrote:
> > Won't it be a good thing, if you instead of showing all of us, that
> > you
> > can tell where people fail to present something in the right way,
> > help and guide them to write the necessary things like PMS patches,
> > GLEPs etc., so that we can proceed in an efficient way? 
> 
> 	That's not his style. Never has been, and I don't see that
> changing.

Yeah, I'm afraid I'm not available for hire to work full time on
providing basic tutoring and hand-holding on design and technical
writing -- it's not really my cup of tea. But if you have the money,
there are plenty of others who make their livings teaching that sort of
thing.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Maxim Kammerer]

On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao <ryao@gentoo.org> wrote:
> Multilib (and/or multiarch) support

Sorry for a possibly ignorant question. Does multilib support include
the ability to build Busybox against uclibc (on a glibc system)?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] My wishlist for EAPI 5

[Ciaran McCreesh]

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

On Wed, 20 Jun 2012 23:39:42 +0300
Maxim Kammerer <mk@dee.su> wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao <ryao@gentoo.org> wrote:
> > Multilib (and/or multiarch) support
> 
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?

Nobody knows, since everyone you ask has a different idea of what
multilib is.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Richard Yao]

On 06/20/2012 04:39 PM, Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao <ryao@gentoo.org> wrote:
>> Multilib (and/or multiarch) support
>
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?

It includes it no more than portage does currently.

Re: [gentoo-dev] My wishlist for EAPI 5

[Mike Frysinger]

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

On Wednesday 20 June 2012 16:39:42 Maxim Kammerer wrote:
> On Wed, Jun 20, 2012 at 11:25 PM, Richard Yao wrote:
> > Multilib (and/or multiarch) support
> 
> Sorry for a possibly ignorant question. Does multilib support include
> the ability to build Busybox against uclibc (on a glibc system)?

i'm not sure Richard knows exactly what he is asking for.  multilib does not 
cover different C libraries, but multiarch does.  the former is what Thomas has 
been working on (multilib portage) while the later is basically cross-
compiling (use crossdev) and is unrealistic for EAPI=5 integration (and i 
might even say isn't really a problem anymore that needs "solving").
-mike

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

Re: [gentoo-dev] My wishlist for EAPI 5

[Luca Barbato]

On 06/20/2012 10:25 PM, Richard Yao wrote:
> Here is my wishlist for EAPI 5:
> 
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
> 
> Here are some explanations:
> 
> Multilib (and/or multiarch) support
> 	The current binaries cause a great deal of pain, particularly when a
> user does not want to upgrade something. I had this problem with WINE
> and glibc because I wanted to avoid the reverse memcpy() fiasco on my
> systems. This situation would have been avoided entirely if the package
> manager supported multilib.
> 
> Automated epatch_user support
> 	Users should be able to test patches without modifying their ebuilds.
> This also saves developer time because we don't need to navigate the
> portage tree (or an overlay), make a change and test it. We could just
> dump the patch in the appropriate directory and build.
> 
> Parallel make checks
> 	As it stands, `make check` is so slow that few people actually run it
> and QA suffers as a result. We have the ability to do parallel checks,
> but we need to explicitly put `emake check` into the ebuild and use
> autoconf 1.12 to get that. It would be best if this behavior were the
> default, not the exception.
> 
> POSIX Shell compliance
> 	There has been a great deal of work done to give the user full control
> of what is on his system and there is more that we can do there. In
> particular, I think a lean Gentoo Linux system should be able to use
> busybox sh and nothing else. That requires POSIX shell compliance.
> OpenRC init scripts support this and the configure scripts support this.
> The few exceptions are bugs that are addressed by the Gentoo BSD developers.
> 	As such, I think we should make EAPI=5 use POSIX shell by default. If
> an ebuild requires bash, we can allow the ebuild to declare that (e.g.
> WANT_SH=bash), but that should be the exception and not the rule.

It is more likely to succeed either adding to busybox the missing bits
of bash we use or forking bash (so eventually it could be developed on a
source repo) and making it lean and fast for our specific purposes.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] My wishlist for EAPI 5

[Alec Warner]

On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao <ryao@gentoo.org> wrote:
> Here is my wishlist for EAPI 5:
>
> Multilib (and/or multiarch) support
> Automated epatch_user support
> Parallel make checks
> POSIX Shell compliance
>
> Here are some explanations:
>
> Multilib (and/or multiarch) support
>        The current binaries cause a great deal of pain, particularly when a
> user does not want to upgrade something. I had this problem with WINE
> and glibc because I wanted to avoid the reverse memcpy() fiasco on my
> systems. This situation would have been avoided entirely if the package
> manager supported multilib.
>
> Automated epatch_user support
>        Users should be able to test patches without modifying their ebuilds.
> This also saves developer time because we don't need to navigate the
> portage tree (or an overlay), make a change and test it. We could just
> dump the patch in the appropriate directory and build.
>
> Parallel make checks
>        As it stands, `make check` is so slow that few people actually run it
> and QA suffers as a result. We have the ability to do parallel checks,
> but we need to explicitly put `emake check` into the ebuild and use
> autoconf 1.12 to get that. It would be best if this behavior were the
> default, not the exception.
>
> POSIX Shell compliance
>        There has been a great deal of work done to give the user full control
> of what is on his system and there is more that we can do there. In
> particular, I think a lean Gentoo Linux system should be able to use
> busybox sh and nothing else. That requires POSIX shell compliance.
> OpenRC init scripts support this and the configure scripts support this.
> The few exceptions are bugs that are addressed by the Gentoo BSD developers.
>        As such, I think we should make EAPI=5 use POSIX shell by default. If
> an ebuild requires bash, we can allow the ebuild to declare that (e.g.
> WANT_SH=bash), but that should be the exception and not the rule.
>

Our ebuilds are written in bash. I dunno about you, but bash sucks for
writing anything remotely complicated in. My goal is any script that
is 200 lines of bash or more gets rewritten in something else (usually
python.) I mean the canonical example here is the old python.eclass
which was a masterful example of how bash can really be used to shoot
yourself in the foot.

However I'd argue that the opposite of what Ciaran said is true. Screw
trying to get the PM to stop using bash; developers are not interested
in writing ebuilds in posix shell; bar none.

Why would I as an ebuild author waste a bunch of time writing my
ebuild in posix compatible sh when I can use bash (and if I had a
better language than bash to write ebuilds in; I'd use that too.) You
are free to write your ebuilds in posix sh; good luck to you.

-A

Re: [gentoo-dev] My wishlist for EAPI 5

[Ben de Groot]

On 21 June 2012 05:33, Alec Warner <antarus@gentoo.org> wrote:
> On Wed, Jun 20, 2012 at 10:25 PM, Richard Yao <ryao@gentoo.org> wrote:
>> Here is my wishlist for EAPI 5:
[...]
>> POSIX Shell compliance
>>        There has been a great deal of work done to give the user full control
>> of what is on his system and there is more that we can do there. In
>> particular, I think a lean Gentoo Linux system should be able to use
>> busybox sh and nothing else. That requires POSIX shell compliance.
>> OpenRC init scripts support this and the configure scripts support this.
>> The few exceptions are bugs that are addressed by the Gentoo BSD developers.
>>        As such, I think we should make EAPI=5 use POSIX shell by default. If
>> an ebuild requires bash, we can allow the ebuild to declare that (e.g.
>> WANT_SH=bash), but that should be the exception and not the rule.
>>
>
> Our ebuilds are written in bash. [...] Screw
> trying to get the PM to stop using bash; developers are not interested
> in writing ebuilds in posix shell; bar none.
>
> Why would I as an ebuild author waste a bunch of time writing my
> ebuild in posix compatible sh when I can use bash (and if I had a
> better language than bash to write ebuilds in; I'd use that too.) You
> are free to write your ebuilds in posix sh; good luck to you.

Ebuilds are written in bash. And the convenience of using bash
far outweighs any benefits of using posix sh instead. One needs
to make a very strong case to convince enough developers to
change this...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

Re: [gentoo-dev] My wishlist for EAPI 5

[Mike Frysinger]

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

On Wednesday 20 June 2012 16:25:30 Richard Yao wrote:
> Multilib (and/or multiarch) support

Thomas already has multilib documents put together for review.  multiarch 
doesn't make sense for us, and even if it did, there's no way it'd be spec-ed 
out in a reasonable time frame for EAPI=5 (or even 6 or 7 or ...).

> 	The current binaries cause a great deal of pain, particularly when a
> user does not want to upgrade something. I had this problem with WINE
> and glibc because I wanted to avoid the reverse memcpy() fiasco on my
> systems. This situation would have been avoided entirely if the package
> manager supported multilib.

i don't buy this argument and makes me think when you say "multilib", you 
don't actually mean "multilib".

> Automated epatch_user support
> 	Users should be able to test patches without modifying their ebuilds.
> This also saves developer time because we don't need to navigate the
> portage tree (or an overlay), make a change and test it. We could just
> dump the patch in the appropriate directory and build.

putting forth an idea is one thing.  working out the technical aspects is 
different.  this sounds like something destined for EAPI=6: currently, 
epatch_user uses epatch, and that provides a lot of dynamic patch support that 
doesn't fit well with being spec-ed out / encoded in PMS.

> Parallel make checks

SGTM

> POSIX Shell compliance
> 	There has been a great deal of work done to give the user full control
> of what is on his system and there is more that we can do there. In
> particular, I think a lean Gentoo Linux system should be able to use
> busybox sh and nothing else. That requires POSIX shell compliance.
> OpenRC init scripts support this and the configure scripts support this.
> The few exceptions are bugs that are addressed by the Gentoo BSD
> developers. As such, I think we should make EAPI=5 use POSIX shell by
> default. If an ebuild requires bash, we can allow the ebuild to declare
> that (e.g. WANT_SH=bash), but that should be the exception and not the
> rule.

not a chance, and your logic about "choice" really makes no sense in the 
ebuild context.  read the archives wrt Roy Maples (sadly) burning out for in-
depth details as to why this is a no-go.
-mike

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