[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packaging Arcan
From: |
L p R n d n |
Subject: |
Re: Packaging Arcan |
Date: |
Fri, 23 Nov 2018 13:54:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Thanks Pierre for your quick answer!
Pierre Neidhardt <address@hidden> 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