Re: Debugging info unavailability

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]

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

> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>
>>>>> Adding the "debug" to the default value of <package> would every package
>>>>> to now have a debug output; isn't this why Danny suggested to only
>>>>> change it at the build system level? That way nothing which doesn't have
>>>>> debugging symbols by default would break or have a useless debug output.
>>>>
>>>> Yes, it’s tempting to do it at the build-system level.  However, there
>>>> would now be a discrepancy between the actual outputs of the package
>>>> derivations and those of the package object: the package object would
>>>> declare just one output, but the corresponding derivation would have two
>>>> outputs.
>>>>
>>>
>>> Thanks for pointing that! It would be a Bad Thing indeed to introduce a
>>> mismatch between the package definition and the corresponding store
>>> item...
>>>
>>> Possibly another Bad Idea, but we could leave things as they are... And
>>> run a script which would rewrite (really, at the package definition
>>> level) the package outputs to include "debug" for every package built
>>> using the gnu/glib-or-gtk build systems? The commit will not be
>>> pretty, that would bring us where we want to be? Being Scheme, that'd be
>>> somewhat easy.
>>
>> This sounds better.  I just don’t know if Hydra would have enough space
>> for all of these additional outputs.
>>
>> Can we increase storage space on Hydra already or do we need to wait for
>> bayfront to replace the server in Boston?
>
> I don’t think we can have more space easily on hydra.gnu.org.
>
> I’m also unsure how much would be needed.  Currently ‘guix publish’
> prepares bakes archives on-demand.  So if you ask for glibc:out, it
> returns 404, prepares it, and the next request for glibc:out will
> succeed.  But if you ask for glibc:debug, it’s similarly missing
> initially.
>
> With this model, ‘guix publish’ gives the impression that not all the
> outputs of a given derivation are available at the same time.
>
> We could change ‘guix publish’ to “bake” all the outputs of a derivation
> as soon as one if requested—e.g., when you ask for glibc:out, it bakes
> not only glibc:out but also glibc:debug.  But then we might have a disk
> space issue.
>
> Thoughts?
>
> Ludo’.

The ideal situation would be to not be space contrived and to build a cache
everything or at least following some heuristic such as "every package that
was requested at least once in the past month". For someone following
master, I find that the current way substitutes are built is not
aggressive enough, and I find often find myself building the world with
--fallback.

What good is a substitute server if it doesn't hold the stuff I need
*now*? :) On the other side, it really makes me want to look at GNUnet,
which seems like the better long term solution.

I'll investigate the script to add "debug" to our gnu/gtk packages.

Maxim

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]