[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] cubieboard2/truck users and opam 1.2

On 3 Nov 2014, at 13:07, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> On 3 November 2014 09:48, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 3 Nov 2014, at 09:12, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> On 3 November 2014 00:02, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>>> That should work, but it's always better to grab the binary compiled on the
>>>> target distro if at all possible.  The PPA remote will also give you all 
>>>> the
>>>> other binaries (like opam-admin) which aren't essential for basic usage, 
>>>> but
>>>> will get pretty confusing if you try to use an older opam-admin in the
>>>> future.
>>> By the way, it would be slightly more convenient for 0install too if
>>> these were sub-commands ("opam installer" vs "opam-installer"), since
>>> "0install add" has the user provide the top-level command name. This
>>> is for security reasons, so that packages can't add commands to the
>>> user's PATH without an explicit request from the user.
>> Doesn't git have problems with 0install as well then?  The extension
>> mechanism is the same -- multiple binaries with <base>-<extension> that
>> are looked up by the <base> command in the path.
> There's no problem if the program needs extra commands internally,
> because 0install can add the necessary directory to PATH when it runs
> it. The problem is if you want to provide additional commands to be
> invoked directly by the user.
>> Munging all the commands into the mainline binary will eventually break
>> something that can't be linked, such as the opam-installext shell script.
> I hit the problem when trying assemblage, which assumes opam-installer
> is in the user's path. I guess even making it a sub-command of opam
> isn't right, since opam might not be installed either.

It does sound like we need a separate opam-installer package here, since
assemblage doesn't depend on OPAM (only on opam-installer).


MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.