[Top][All Lists]

[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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]