| 1 |
>>>>> On Thu, 10 Mar 2016, Alexis Ballier wrote: |
| 2 |
|
| 3 |
> On Wednesday, March 9, 2016 5:37:08 PM CET, Andreas K. Hüttel wrote: |
| 4 |
>> 1) All pre-PMS, non-PMS-conformant behaviour should be considered |
| 5 |
>> deprecated immediately. |
| 6 |
>> 2) We encourage creation of trackers to hunt down and kill pre-PMS, |
| 7 |
>> non-PMS-conformant behaviour of ebuilds, eclasses, package managers |
| 8 |
>> 3) We introduce a hard deadline when all this should be fixed. |
| 9 |
|
| 10 |
> You seem to be generalizing to all cases from a very specific one: |
| 11 |
> multislot is breaking an important assumption (SLOT being constant) |
| 12 |
> and dropping it is not breaking anything. |
| 13 |
|
| 14 |
> Some examples that would fall under the scope of your proposal: |
| 15 |
|
| 16 |
> https://bugs.gentoo.org/show_bug.cgi?id=202631 |
| 17 |
> -> Needed to comply with other PMS rules on some systems ('patch' |
| 18 |
> being GNU patch inside ebuilds, etc.) |
| 19 |
|
| 20 |
No, it isn't. The package manager is required to ensure that "sed", |
| 21 |
"patch", "find" etc. are the GNU versions. This is independent of any |
| 22 |
profile.bashrc. If Portage relies on aliases set in profiles instead, |
| 23 |
then this is a Portage bug which should be fixed. |
| 24 |
|
| 25 |
PMS reference: |
| 26 |
https://projects.gentoo.org/pms/6/pms.html#x1-12600011.3.1.1 |
| 27 |
|
| 28 |
> https://bugs.gentoo.org/show_bug.cgi?id=203891 |
| 29 |
> -> Without this, we'd install a half-broken glibc by default. Any |
| 30 |
> deadline would have to take in consideration the time needed to have |
| 31 |
> a fixed glibc in stable. |
| 32 |
|
| 33 |
> (some ocaml stuff are also offenders here, but it is really minor in |
| 34 |
> comparison, and I've been trying to move away from the "feature" |
| 35 |
> causing the need for it as much as I could) |
| 36 |
|
| 37 |
We have discussed this at length (on the verge of derailing) in |
| 38 |
the bug. Someone has to write a spec, then it can go into EAPI 7. |
| 39 |
I actually like mgorny's proposal for a "dostrip" in comment 39. |
| 40 |
|
| 41 |
Until then, ebuilds should neither rely on the variable, nor should |
| 42 |
they call functions like prepallstrip that are internal to the package |
| 43 |
manager. |
| 44 |
|
| 45 |
PMS reference: |
| 46 |
https://projects.gentoo.org/pms/6/pms.html#x1-14500011.3.3.16 |
| 47 |
|
| 48 |
> https://bugs.gentoo.org/show_bug.cgi?id=573306 |
| 49 |
> -> Needed to get cross-compilation (or even ROOT!=/) to work |
| 50 |
> properly. (Independtly of PM getting cross-compilation deps |
| 51 |
> properly). |
| 52 |
|
| 53 |
I cannot say much about this one, or about cross-compilation in |
| 54 |
general. Reading the bug, I am not too optimistic, though. Seems there |
| 55 |
aren't even clear answers to the three simple questions that have been |
| 56 |
posed. |
| 57 |
|
| 58 |
> The above examples are needed in order to be able to provide working |
| 59 |
> stuff, predate PMS and do not conform to it. The only issue they |
| 60 |
> cause is that alternative PMs might not implement them properly. |
| 61 |
|
| 62 |
Well, the first PMS version was approved by the council in 2008 |
| 63 |
(for EAPI 2). At some point we should have tracked down all remaining |
| 64 |
non-PMS-conformant behaviour, so it can be fixed in ebuilds, in the |
| 65 |
package manager, or in the PMS itself. |
| 66 |
|
| 67 |
So +1 for Andreas's items 1) and 2). Not so sure about item 3) though. |
| 68 |
For some things a hard deadline could work, but for others like |
| 69 |
cross-compiling it may not. |
| 70 |
|
| 71 |
Ulrich |
Archives