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

[Thomas Leonard <talex5@xxxxxxxxx>]

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's a bit of a hacky situation, using 0install to install a
non-0install package, but it would be nice if it worked out of the
box. A cleaner solution might replace "make install" with "assemblage
install", where "assemblage" comes from 0install and can have its
dependencies provided automatically, but I understand people like
things to work with plain make.

>> I'll try to get the OPAM 0install binaries updated to 1.2 from
>> 1.2-beta4 soon too.
>
> Great!

Done. BTW, I tried using ocaml-github to upload the releases, but
couldn't get it to accept my authentication token. Might be something
to do with 2-factor auth, but it worked with curl...

(alternativelty, if the binaries were released as tarballs, we could
use the upstream URLs)

> -anil
>
>>
>>> -anil
>>>
>>>
>>> On 2 Nov 2014, at 23:56, Luke Dunstan <lukedunstan81@xxxxxxxxx> wrote:
>>>
>>> A week ago I started using this binary:
>>> https://github.com/ocaml/opam/releases/download/1.2.0/opam-1.2.0-armv7l-Linux
>>>
>>> I just renamed it to "opam" and put it in a directory that is earlier in
>>> PATH than /usr/bin. It seems to work fine, but is there any reason why this
>>> might cause problems?
>>>
>>> Luke
>>>
>>>
>>> On 3 November 2014 06:50, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>>>
>>>>
>>>> On 2 Nov 2014, at 22:46, David Scott <scott.dj@xxxxxxxxx> wrote:
>>>>
>>>>
>>>>
>>>> On Sun, Nov 2, 2014 at 8:57 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>>>>
>>>>> For Cubieboard2 users, the Launchpad OPAM builds do end up with armhf
>>>>> images, but you can't use the PPA commands since the distribution template
>>>>> of our Cubie image is 'Linaro' instead of 'Ubuntu' (not sure why we can't
>>>>> just switch to a pure Ubuntu or Debian image).
>>>>>
>>>>> Anyway, these four simple commands will get you OPAM 1.2.0 without having
>>>>> to do a source compilation, as root:
>>>>>
>>>>> echo "deb http://ppa.launchpad.net/avsm/ocaml41+opam12/ubuntu trusty
>>>>> main"  > /etc/apt/sources.list.d/ppa-opam.list
>>>>> apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5B2D0C5561707B09
>>>>> apt-get update
>>>>> apt-get upgrade
>>>>
>>>>
>>>> This worked nicely for me. I was able to (from memory, hope I've not
>>>> typo'ed it)
>>>>
>>>> opam init
>>>> eval `opam config env`
>>>> opam remote add mirage-dev git://github.com/mirage/mirage-dev
>>>> opam install mirage
>>>> git clone git://github.com/mirage/mirage-skeleton
>>>> cd mirage-skeleton
>>>> MODE=xen make configure
>>>> MODE=xen make build
>>>>
>>>> and all the examples built ok.
>>>>
>>>>
>>>> Coincidentally, the same as
>>>> https://github.com/mirage/is-mirage-broken/blob/master/scripts/build_mirage
>>>> !
>>>>
>>>> -anil
>>>>
>>>>
>>>> _______________________________________________
>>>> MirageOS-devel mailing list
>>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> MirageOS-devel mailing list
>>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
>>>
>>
>>
>>
>> --
>> Dr Thomas Leonard        http://0install.net/
>> GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
>> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA
>



-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel