Re: Packaging Arcan

[L p R n d n <guix@lprndn.info>]

Thanks Pierre for your quick answer!

Pierre Neidhardt <mail@ambrevar.xyz> writes:

>> 3.a. For qemu, I fear the produced binaries would conflict with the
>> original ones. Is there something we can do in the build process to deal
>> with that can of thing or sould we just expect the user deal with it on
>> its own as Guix doest it very well on its own?
>
> The specialized qemu should be an input to arcan, not a propagated input.
> This way it won't conflict with anything.
>
> You might have to configure or patch arcan so that it finds the specialized qemu
> binaries in the input store folder.
>

My bad here, I should have been clearer in my explaination. The patched
Qemu is not used during build but during runtime. From my understanding,
it's provided as a way to start X applications under Arcan. The patch is
probably just used to give qemu the ability to communicate with Arcan
server. So using 'guix environment' might just be a good solution. (I
wonder if it could be possible to user guix containers in the same way...)

>> 3.b. The patched openal is used during build to produce a special binary
>> (arcan_lwa which allows nested servers). It should normally be fetched
>> during build time which is obviously not possible here. I suppose there
>> is no clear answer here but how would you deal with that kind of
>> behaviour? Create a modified openal package? Can we fetch multiple sources?
>
> This happens a lot with other packages (e.g. the Go build system).  The answer
> is simple: package the specialized OpenAL and provide it as input.
> If arcan still insists on downloading openal, patch it so that it does not.

I'll look iton tis! ;)

> Hope that helps!
>

Lprndn