| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 08/01/2012 08:29 AM, Fabian Groffen wrote: |
| 5 |
> In a little less than two weeks from now, the council will meet |
| 6 |
> again. This is the time to raise and prepare items that the council |
| 7 |
> should put on the agenda to vote on. |
| 8 |
> |
| 9 |
> Please respond to this email with agenda items. Please do not |
| 10 |
> hestitate to repeat your agenda item here with a pointer if you |
| 11 |
> previously suggested one (since the last meeting). |
| 12 |
> |
| 13 |
> The agenda for the next meeting will be sent out a week before the |
| 14 |
> meeting by the meeting's chairman. |
| 15 |
> |
| 16 |
> Please respond to gentoo-project list, if possible. |
| 17 |
> |
| 18 |
> |
| 19 |
|
| 20 |
As per devmanual |
| 21 |
http://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html |
| 22 |
build log should always be verbose. |
| 23 |
|
| 24 |
A tracker has been added: |
| 25 |
https://bugs.gentoo.org/show_bug.cgi?id=429308 |
| 26 |
|
| 27 |
However, it does not make much sense to fix all of this per-package, |
| 28 |
since we can change the behavior of certain build systems. For cmake |
| 29 |
this has been mostly fixed via cmake-utils.eclass. |
| 30 |
|
| 31 |
For autotools based build systems we need to modify econf as it has |
| 32 |
already been done in: |
| 33 |
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1cc39de72ac5311db748341ef9183586556719d9 |
| 34 |
(add --disable-silent-rules if the configure script has this option) |
| 35 |
and then reverted again, cause PMS guys intervened this will cause |
| 36 |
breakage, because './configure --help' will be unconditionally invoked |
| 37 |
by econf (however this is already the case for EAPI=4, but not for 0-3). |
| 38 |
|
| 39 |
reason for this commit was: |
| 40 |
In order to have consistent behavior that follows this gentoo policy |
| 41 |
accross the whole tree we should always try to fix this above |
| 42 |
per-package level, either on eclass or PM level. |
| 43 |
Otherwise we will have to file many bugs for this. This has actually |
| 44 |
been requested by another dev who was annoyed by my bugreports. |
| 45 |
|
| 46 |
========== |
| 47 |
The council should vote on the following: |
| 48 |
1. apply that portage commit again and add that information to PMS |
| 49 |
retroactively. |
| 50 |
2. If point 1 is declined, then vote on applying this to EAPI=4 |
| 51 |
retrocatively since this one already calls './configure --help'. |
| 52 |
========== |
| 53 |
|
| 54 |
Why point 1 should be declined as per PMS guys opinion: |
| 55 |
It may break ebuilds and changes older EAPIs behavior. |
| 56 |
|
| 57 |
Why point 2 should be declined as per some random guys opinion: |
| 58 |
It changes older EAPIs behavior. |
| 59 |
|
| 60 |
Why point 1 should be accepted IMO: |
| 61 |
If this only applies to EAPI=4 then all affected packages using EAPI=3 |
| 62 |
or lower would either need an EAPI-bump or append |
| 63 |
- --disable-silent-rules to econf. |
| 64 |
Both is per-package level and will result in many many bugs being |
| 65 |
filed again (and I predict many of them will just be ignored, because |
| 66 |
devs will be annoyed by them). |
| 67 |
If an ebuild that uses EAPI=3 breaks, because econf simply calls |
| 68 |
'./configure --help', then it is already borked and should be fixed, |
| 69 |
cause it's using a handcrafted configure script with econf which was |
| 70 |
designed for autotools based build systems. |
| 71 |
This is not a strong reason to avoid this retroactive change which |
| 72 |
will bring us consistent behavior regarding autotools based build systems. |
| 73 |
|
| 74 |
Why at least point 2 should be accepted IMO: |
| 75 |
There is no technical argument against it. No one could think of any |
| 76 |
kind of breakage this might cause to EAPI=4 + we have at least a |
| 77 |
retroactive fix for this one to get SOME consistent behavior for the |
| 78 |
tree. It will take years until the majority of ebuilds will have |
| 79 |
migrated to EAPI=5. |
| 80 |
Don't rely on future EAPIs to fix current problems within the tree. |
| 81 |
|
| 82 |
|
| 83 |
You can follow part of the discussion on: |
| 84 |
https://bugs.gentoo.org/show_bug.cgi?id=379497 |
| 85 |
|
| 86 |
|
| 87 |
Don't discuss this here please. I just tried to sum it up, so I might |
| 88 |
have missed something. |
| 89 |
-----BEGIN PGP SIGNATURE----- |
| 90 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 91 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 92 |
|
| 93 |
iQEcBAEBAgAGBQJQI8TBAAoJEFpvPKfnPDWzM5IH/2bzr4Z8HwgCUw7mihvp2VDg |
| 94 |
Ld26sgtn0s/MpaqAeA+6LjgNG26bAmk19bNYhd7Atm1LoYTsPFzLuiYYQDv6wGZN |
| 95 |
Bf+3/n5YYXgPAwkD9q9q/h1fTHl45CSycd73gL8a3/3jVcEt9HX+9Qp7g7ZnD/NQ |
| 96 |
dWD1c3snb5I9iUbOZZw75IauJZujxN4AnWxp2Z1ncGl5xHrjIgOY0RPbHFDWyUyj |
| 97 |
tOPBh1SQIEPmkjagcb9vHXrSQMiTj4+TJH8xqN3yPR7ZYu76TijV8WOnBjUsrHpW |
| 98 |
QxOEzaShd1mHpc2tWn1vi/stvdZQttxXGihc+d8HNFJYJ3z9kULfRVGyOuS3qkg= |
| 99 |
=NVAx |
| 100 |
-----END PGP SIGNATURE----- |
Archives