Ticket #1329 (new defect)

Opened 5 years ago

Last modified 5 years ago

Associative array and loadsaveenv

Reported by: Vality Owned by:
Priority: Sometime Milestone:
Component: core/paludis Version: 2.4.0
Keywords: Cc:
Blocked By: Blocking:
Distribution: N/A

Description

Firstly, apologies if I have somehow screwed up and this is an environment or ebuild issue, not an issue with paludis.

I am currently trying to emerge dev-util/dub-0.9.23 from the dlang overlay. It is breaking the build at the point of trying ">>> Starting builtin_loadenv" then falls over. with the error:

Error:
  * In program cave perform install --hooks --managed-output --output-exclusivity with-others =dev-util/dub-0.9.23:0::dlang --destination installed --x-of-y 1 of 1:
  * When installing 'dev-util/dub-0.9.23:0::dlang':
  * When running an ebuild command on 'dev-util/dub-0.9.23:0::dlang':
  * Install failed for 'dev-util/dub-0.9.23:0::dlang' (paludis::ActionFailedError)

/var/tmp/paludis/dev-util-dub-0.9.23/temp/loadsaveenv: line 415: 2.063: syntax error: invalid arithmetic operator (error token is ".063")

Looking at that line in the file it is:

__dlang_dmd_frontend_mapping=([2.063]="2.063 x86 amd64" [2.066]="2.066 x86 amd64" [2.067]="2.067" [2.064]="2.064 x86 amd64" [2.065]="2.065 x86 amd64" )

What this looks like is that the script is trying to assign to an undeclared associative array and failing, assuming it is a normal array. When I looked into the eclass it is indeed running:

declare -gA __dlang_dmd_frontend_mapping

but this declaration is not being run in the loadsaveenv script.

Change History

comment:1 follow-up: ↓ 2 Changed 5 years ago by ciaranm

Pretty sure ebuilds aren't allowed to use associative arrays. There's a maximum bash version they're allowed to rely upon, and I don't think that version has them.

comment:2 in reply to: ↑ 1 Changed 5 years ago by Vality

Replying to ciaranm:

Pretty sure ebuilds aren't allowed to use associative arrays. There's a maximum bash version they're allowed to rely upon, and I don't think that version has them.

If there is some documentation of this I would be more than happy to contact the author of the overlay and see if I can help them fix the ebuilds to not rely on this. However I couldn't find anything official which stated one way or the other but that may just be because I didn't look far enough.

Though as an aside I would not be surprised if this were to become permitted in a future EAPI even if it is forbidden now. So that may be worth thinking about. At very least I think producing a more coherent error could avoid confusion in debugging ebuilds.

comment:3 Changed 5 years ago by ciaranm

It'll be in PMS.

Note: See TracTickets for help on using tickets.