Matching debug symbol and package versions

Hi all,

assume I have installed some package

/gnu/store/xxx-daemon-1.0

After a while I notice that it's inexplicably hanging, so I do 'guix

package -i daemon-1.0:debug', attach to the daemon with gdb, and...no

debug symbols can be loaded! Turns out, in the meantime the hash has

changed so i installed

/gnu/store/yyy-daemon-1.0:debug

It seems to me that there is currently no possibility to get the correct

debug symbols. Worse, as civodul mentioned in chat, the package hash is

part of the symbols itself, so I can't even cheat and force gdb manually

to use the symbols for version yyy.

Benno Evers <benno@bmevers.de> skribis:

One thing that could be done, maybe, is for ‘guix package -i’ to try to

infer the right item to install.

That is, when running “guix package -i foo:bar”:

1. If no ‘foo’ is present in the profile, install the latest

‘foo:bar’, as is already the case.

2. If another output of ‘foo’ is already installed, do:

2a. Retrieve the .drv for that item using ‘query-path-info’.

i. If the .drv is present, parse it, and use the outputs

specified therein–i.e., the one that match.

ii. If the .drv is missing, well, install the latest ‘foo:bar’.

The obvious problem is that this all sounds a bit complex, and it’s

unclear whether case (i) would sufficiently frequent to justify this

complexity.

Thoughts?

Thanks,

Ludo’.

On Tue, 27 Oct 2015 16:56:23 +0100

ludo@gnu.org (Ludovic Courtès) wrote:

Less complex would be `guix package -i foo:bar` to effectively be `guix

package -i foo foo:bar`. But then if you really only wanted foo:bar you'd

have to follow up with `guix package -r foo`.

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

Efraim Flashner <efraim@flashner.co.il> skribis:

But I think that’s not necessarily what you’d expect, nor what you’d want.

Ludo’.

Benno Evers <benno@bmevers.de> skribis:

I realized that I quickly focused on the issue without looking at the

more general context.

The “in the meantime” above means that you had run ‘guix pull’ or

similar, thereby making the previous package recipe unavailable and

leaving you unable to install matching debugging symbols.

On my laptop, I typically run ‘guix package -u’ every time I do ‘guix

pull’, so I cannot find myself in a situation where I’m unable to

install debugging symbols of already installed packages.

This is just to say that the scenario described here can indeed happen,

but is probably not that common. And I don’t mean this to be an excuse

to avoid difficult work. ;-)

I think that the solutions I proposed are worse than the problem,

because they’re complex and would depend on external state, thus making

them look non-deterministic.

So I think I’ll punt and mark it as “wontfix.”

Thoughts?

Ludo’.

tags 21767 wontfix

close 21767 0.9.0