| 1 |
On 17/06/2022 18.27, William Hubbs wrote: |
| 2 |
> On Mon, Jun 13, 2022 at 12:26:43PM +0200, Ulrich Mueller wrote: |
| 3 |
>>>>>>> On Mon, 13 Jun 2022, Florian Schmaus wrote: |
| 4 |
>> |
| 5 |
>>>>>> Judging from the gentoo-dev@ mailing list discussion [1] about EGO_SUM, |
| 6 |
>>>>>> where some voices where in agreement that EGO_SUM has its raison d'être, |
| 7 |
>>>>>> while there where no arguments in favor of eventually removing EGO_SUM, |
| 8 |
>>>>>> I hereby propose to undeprecate EGO_SUM. |
| 9 |
>>>>>> |
| 10 |
>>>>>> 1: https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa |
| 11 |
>> |
| 12 |
>>>> Can this be done without requesting changes to package managers? |
| 13 |
>> |
| 14 |
>>> What is 'this' here? |
| 15 |
>> |
| 16 |
>> Undeprecating EGO_SUM. |
| 17 |
>> |
| 18 |
>>> The patchset does not make changes to any package manager, just the |
| 19 |
>>> go-module eclass. |
| 20 |
>> |
| 21 |
>>> Note that this is not about finding about an alternative to dependency |
| 22 |
>>> tarballs. It is just about re-allowing EGO_SUM in addition to |
| 23 |
>>> dependency tarballs for packaging Go software in Gentoo. |
| 24 |
> |
| 25 |
> Like I said on my earlier reply, there have been packages that break |
| 26 |
> using EGO_SUM. |
| 27 |
|
| 28 |
Those packages can't obviously use EGO_SUM, but this should *not* mean |
| 29 |
that we generally ban EGO_SUM. |
| 30 |
|
| 31 |
|
| 32 |
> The most pressing concern about EGO_SUM is that it can make portage |
| 33 |
> crash because of the size of SRC_URI, so it definitely should not be |
| 34 |
> preferred over dependency tarballs. |
| 35 |
|
| 36 |
I think an approach like my posted patch, which makes go-modules.eclass |
| 37 |
invoke 'die' if A exceeds a certain threshold, should make developers in |
| 38 |
most situations aware that it is time to switch their package to use a |
| 39 |
dependency tarball instead of EGO_SUM. |
| 40 |
|
| 41 |
The remaining situations are the ones where a package initially exceeds |
| 42 |
the MAX_ARG_STRLEN limit, and where a certain USE-flag combination |
| 43 |
causes the limit to be exceeded. The former should not be real issue, as |
| 44 |
such ebuilds should never been committed, as they could never work. The |
| 45 |
later can be solved by exhaustive testing of all possible USE flag |
| 46 |
combinations. |
| 47 |
|
| 48 |
- Flow |
Archives