Smalltalk › Squeak › Squeak - Dev

Updating VMs and possible conflicts

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

Chris Cunnington-4

Updating VMs and possible conflicts

I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available.
I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.

About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.

Chris

[1]

BOX3 - start script used

TEST FOR VERSION:
cogvm -version r2776

/usr/bin/cogvm

BINARIES AVAILABLE:
/usr/lib/squeak/4.0-2776
/usr/local/lib/squeak/4.10.2-2793
/home/chrismuller/vm/lib/squeak/4.0-2761
/home/chrismuller/vm/lib/4.4.7-2357

localdebs:
cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
squeak-sources_4.1-1_all.deb

BOX3 - no start script used?

TEST FOR VERSION:
squeak -version
cannot find VM to run image 'squeak' with option ''

BINARIES AVAILABLE:
/usr/local/lib/squeak/4.10.2-2793/squeakvm
/home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
/var/lib/jenkins/jobs/*

localdebs:
squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb

David T. Lewis

Re: [Box-Admins] Updating VMs and possible conflicts

The interpreter VM is installed on both box3 and box4. The debs are in
/root/localdebs and a record of the installation is in the log file in the
root account (I don't remember the name).

Dave

> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade
> box4 to the latest Cog (non-Spur) VM available.
> I think I can do that in box4 with no fuss, as I don't think the
> Interpreter VM is installed. So I don't expect a conflict. It is worth
> noting that some binaries are stored in /usr/local/lib and others in
> /usr/lib.
>
> About where to put the .deb files. I guess the proper thing is to use
> cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>
> Chris
>
>
> [1]
>
> BOX3 - start script used
>
> TEST FOR VERSION:
> cogvm -version r2776
>
> /usr/bin/cogvm
>
> BINARIES AVAILABLE:
> /usr/lib/squeak/4.0-2776
> /usr/local/lib/squeak/4.10.2-2793
> /home/chrismuller/vm/lib/squeak/4.0-2761
> /home/chrismuller/vm/lib/4.4.7-2357
>
> localdebs:
> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
> squeak-sources_4.1-1_all.deb
>
>
> BOX3 - no start script used?
>
> TEST FOR VERSION:
> squeak -version
> cannot find VM to run image 'squeak' with option ''
>
> BINARIES AVAILABLE:
> /usr/local/lib/squeak/4.10.2-2793/squeakvm
> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
> /var/lib/jenkins/jobs/*
>
>
> localdebs:
> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb

Tobias Pape

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Chris Cunnington-4

Just that it is not lost,

debian provides a facility to provide normally incompatible
binaries. (eg, different versions, different vendors)
they call it alternatives. (See /etc/alternatives)

one example: jvm. or cc.
on my server:

$ ls -l /usr/bin/cc
lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc

$ ls -l /etc/alternatives/cc
lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc

and you can select:
$ upate-alternatives --list cc
/usr/bin/gcc
/usr/bin/clang

That way, we could provide different squeakvm's via this tool :)

Best
-Tobias

On 02.07.2014, at 18:27, Chris Cunnington <[hidden email]> wrote:

> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available.
> I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
>
> About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>
> Chris
>
>
> [1]
>
> BOX3 - start script used
>
> TEST FOR VERSION:
> cogvm -version r2776
>
> /usr/bin/cogvm
>
> BINARIES AVAILABLE:
> /usr/lib/squeak/4.0-2776
> /usr/local/lib/squeak/4.10.2-2793
> /home/chrismuller/vm/lib/squeak/4.0-2761
> /home/chrismuller/vm/lib/4.4.7-2357
>
> localdebs:
> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
> squeak-sources_4.1-1_all.deb
>
>
> BOX3 - no start script used?
>
> TEST FOR VERSION:
> squeak -version
> cannot find VM to run image 'squeak' with option ''
>
> BINARIES AVAILABLE:
> /usr/local/lib/squeak/4.10.2-2793/squeakvm
> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
> /var/lib/jenkins/jobs/*
>
>
> localdebs:
> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb

signature.asc (1K) Download Attachment

Chris Cunnington-4

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by David T. Lewis

On Jul 2, 2014, at 12:32 PM, David T. Lewis <[hidden email]> wrote:

> The interpreter VM is installed on both box3 and box4. The debs are in
> /root/localdebs and a record of the installation is in the log file in the
> root account (I don't remember the name).

Yup, I see it. Here it is.

admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb

OK, r2793 is the Interpreter VM and it's installed in both boxes. It's installed in a different location that Cog:

>> /usr/lib/squeak/4.0-2776
>> /usr/local/lib/squeak/4.10.2-2793

To my mind that means there's no naming conflict, but I suspect that's not what you mean. In both box3 and box4 the only script in /usr/bin is cogvm in box4. The interpreter VM has no script to start it, which I think explains why "squeak -version" produces nothing at all; whereas, "cogvm -version" does. And this is the naming convention you want to clear with Eliot, right? What to call the script that starts a VM process? I don't think the Interpreter has one installed on either box.

Closer?

Chris

> Dave
>
>> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade
>> box4 to the latest Cog (non-Spur) VM available.
>> I think I can do that in box4 with no fuss, as I don't think the
>> Interpreter VM is installed. So I don't expect a conflict. It is worth
>> noting that some binaries are stored in /usr/local/lib and others in
>> /usr/lib.
>>
>> About where to put the .deb files. I guess the proper thing is to use
>> cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>>
>> Chris
>>
>>
>> [1]
>>
>> BOX3 - start script used
>>
>> TEST FOR VERSION:
>> cogvm -version r2776
>>
>> /usr/bin/cogvm
>>
>> BINARIES AVAILABLE:
>> /usr/lib/squeak/4.0-2776
>> /usr/local/lib/squeak/4.10.2-2793
>> /home/chrismuller/vm/lib/squeak/4.0-2761
>> /home/chrismuller/vm/lib/4.4.7-2357
>>
>> localdebs:
>> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
>> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
>> squeak-sources_4.1-1_all.deb
>>
>>
>> BOX3 - no start script used?
>>
>> TEST FOR VERSION:
>> squeak -version
>> cannot find VM to run image 'squeak' with option ''
>>
>> BINARIES AVAILABLE:
>> /usr/local/lib/squeak/4.10.2-2793/squeakvm
>> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
>> /var/lib/jenkins/jobs/*
>>
>>
>> localdebs:
>> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
>
>
>

Chris Cunnington-4

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Tobias Pape

On Jul 2, 2014, at 12:59 PM, Tobias Pape <[hidden email]> wrote:

> Just that it is not lost,
>
> debian provides a facility to provide normally incompatible
> binaries. (eg, different versions, different vendors)
> they call it alternatives. (See /etc/alternatives)
>
> one example: jvm. or cc.
> on my server:
>
> $ ls -l /usr/bin/cc
> lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
>
> $ ls -l /etc/alternatives/cc
> lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
>
> and you can select:
> $ upate-alternatives --list cc
> /usr/bin/gcc
> /usr/bin/clang
>
>
> That way, we could provide different squeakvm's via this tool :)

Sounds interesting.

"The generic name is not a direct symbolic link to the selected alterna‐
tive. Instead, it is a symbolic link to a name in the alternatives
directory, which in turn is a symbolic link to the actual file refer‐
enced. This is done so that the system administrator's changes can be
confined within the /etc directory: the FHS (q.v.) gives reasons why
this is a Good Thing."

Chris

> Best
> -Tobias
>
>
> On 02.07.2014, at 18:27, Chris Cunnington <[hidden email]> wrote:
>
>> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to upgrade box4 to the latest Cog (non-Spur) VM available.
>> I think I can do that in box4 with no fuss, as I don't think the Interpreter VM is installed. So I don't expect a conflict. It is worth noting that some binaries are stored in /usr/local/lib and others in /usr/lib.
>>
>> About where to put the .deb files. I guess the proper thing is to use cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>>
>> Chris
>>
>>
>> [1]
>>
>> BOX3 - start script used
>>
>> TEST FOR VERSION:
>> cogvm -version r2776
>>
>> /usr/bin/cogvm
>>
>> BINARIES AVAILABLE:
>> /usr/lib/squeak/4.0-2776
>> /usr/local/lib/squeak/4.10.2-2793
>> /home/chrismuller/vm/lib/squeak/4.0-2761
>> /home/chrismuller/vm/lib/4.4.7-2357
>>
>> localdebs:
>> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
>> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
>> squeak-sources_4.1-1_all.deb
>>
>>
>> BOX3 - no start script used?
>>
>> TEST FOR VERSION:
>> squeak -version
>> cannot find VM to run image 'squeak' with option ''
>>
>> BINARIES AVAILABLE:
>> /usr/local/lib/squeak/4.10.2-2793/squeakvm
>> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
>> /var/lib/jenkins/jobs/*
>>
>>
>> localdebs:
>> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
>
>
>

Bert Freudenberg

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Tobias Pape

On 02.07.2014, at 18:59, Tobias Pape <[hidden email]> wrote:

Nope. That would work only if all VMs could open all images.

- Bert -

smime.p7s (5K) Download Attachment

Tobias Pape

Re: [Box-Admins] Updating VMs and possible conflicts

On 02.07.2014, at 21:02, Bert Freudenberg <[hidden email]> wrote:

>
> On 02.07.2014, at 18:59, Tobias Pape <[hidden email]> wrote:
>
>> Just that it is not lost,
>>
>> debian provides a facility to provide normally incompatible
>> binaries. (eg, different versions, different vendors)
>> they call it alternatives. (See /etc/alternatives)
>>
>> one example: jvm. or cc.
>> on my server:
>>
>> $ ls -l /usr/bin/cc
>> lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
>>
>> $ ls -l /etc/alternatives/cc
>> lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
>>
>> and you can select:
>> $ upate-alternatives --list cc
>> /usr/bin/gcc
>> /usr/bin/clang
>>
>>
>> That way, we could provide different squeakvm's via this tool :)
>
> Nope. That would work only if all VMs could open all images.

Why would that be a requirement?

best
-tobias

signature.asc (1K) Download Attachment

David T. Lewis

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Chris Cunnington-4

The script is installed as /usr/local/bin/squeak.

Yes that is the one that might get stepped on by the Cog install.

>From a Debian packaging point of view, there may be other overlapping
files also.

Dave

>
> On Jul 2, 2014, at 12:32 PM, David T. Lewis <[hidden email]> wrote:
>
>> The interpreter VM is installed on both box3 and box4. The debs are in
>> /root/localdebs and a record of the installation is in the log file in
>> the
>> root account (I don't remember the name).
>
> Yup, I see it. Here it is.
>
> admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
>
> OK, r2793 is the Interpreter VM and it's installed in both boxes. It's
> installed in a different location that Cog:
>
>>> /usr/lib/squeak/4.0-2776
>>> /usr/local/lib/squeak/4.10.2-2793
>
> To my mind that means there's no naming conflict, but I suspect that's not
> what you mean. In both box3 and box4 the only script in /usr/bin is cogvm
> in box4. The interpreter VM has no script to start it, which I think
> explains why "squeak -version" produces nothing at all; whereas, "cogvm
> -version" does. And this is the naming convention you want to clear with
> Eliot, right? What to call the script that starts a VM process? I don't
> think the Interpreter has one installed on either box.
>
> Closer?
>
> Chris
>
>
>> Dave
>>
>>> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to
>>> upgrade
>>> box4 to the latest Cog (non-Spur) VM available.
>>> I think I can do that in box4 with no fuss, as I don't think the
>>> Interpreter VM is installed. So I don't expect a conflict. It is worth
>>> noting that some binaries are stored in /usr/local/lib and others in
>>> /usr/lib.
>>>
>>> About where to put the .deb files. I guess the proper thing is to use
>>> cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>>>
>>> Chris
>>>
>>>
>>> [1]
>>>
>>> BOX3 - start script used
>>>
>>> TEST FOR VERSION:
>>> cogvm -version r2776
>>>
>>> /usr/bin/cogvm
>>>
>>> BINARIES AVAILABLE:
>>> /usr/lib/squeak/4.0-2776
>>> /usr/local/lib/squeak/4.10.2-2793
>>> /home/chrismuller/vm/lib/squeak/4.0-2761
>>> /home/chrismuller/vm/lib/4.4.7-2357
>>>
>>> localdebs:
>>> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
>>> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
>>> squeak-sources_4.1-1_all.deb
>>>
>>>
>>> BOX3 - no start script used?
>>>
>>> TEST FOR VERSION:
>>> squeak -version
>>> cannot find VM to run image 'squeak' with option ''
>>>
>>> BINARIES AVAILABLE:
>>> /usr/local/lib/squeak/4.10.2-2793/squeakvm
>>> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
>>> /var/lib/jenkins/jobs/*
>>>
>>>
>>> localdebs:
>>> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
>>
>>
>>
>

Bert Freudenberg

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Tobias Pape

On 02.07.2014, at 21:03, Tobias Pape <[hidden email]> wrote:

>
> On 02.07.2014, at 21:02, Bert Freudenberg <[hidden email]> wrote:
>
>>
>> On 02.07.2014, at 18:59, Tobias Pape <[hidden email]> wrote:
>>
>>> Just that it is not lost,
>>>
>>> debian provides a facility to provide normally incompatible
>>> binaries. (eg, different versions, different vendors)
>>> they call it alternatives. (See /etc/alternatives)
>>>
>>> one example: jvm. or cc.
>>> on my server:
>>>
>>> $ ls -l /usr/bin/cc
>>> lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
>>>
>>> $ ls -l /etc/alternatives/cc
>>> lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
>>>
>>> and you can select:
>>> $ upate-alternatives --list cc
>>> /usr/bin/gcc
>>> /usr/bin/clang
>>>
>>>
>>> That way, we could provide different squeakvm's via this tool :)
>>
>> Nope. That would work only if all VMs could open all images.
>
> Why would that be a requirement?
>
> best
> -tobias

Because this mechanism is for choosing between alternatives, not for having multiple alternatives at the same time.

If you point /etc/alternatives/squeak to the interpreter, and write a script, it may be fine. If you repoint it later to cog, stuff breaks.

In contrast, gcc and clang are equivalent. They compile the same C files. If you don't care which one to use, you can just use "cc" in a script.

- Bert -

smime.p7s (5K) Download Attachment

Chris Cunnington-4

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by David T. Lewis

On Jul 2, 2014, at 3:04 PM, David T. Lewis <[hidden email]> wrote:

> The script is installed as /usr/local/bin/squeak.
>
> Yes that is the one that might get stepped on by the Cog install.
>
>> From a Debian packaging point of view, there may be other overlapping
> files also.

OK, I see it now. I think these two kinds of VM are being loaded in different places.

/usr/lib/squeak/4.0-2776
/usr/bin/cogvm

/usr/local/lib/squeak/4.10.2-2793
/usr/local/bin/squeak

Chris

> Dave
>
>>
>> On Jul 2, 2014, at 12:32 PM, David T. Lewis <[hidden email]> wrote:
>>
>>> The interpreter VM is installed on both box3 and box4. The debs are in
>>> /root/localdebs and a record of the installation is in the log file in
>>> the
>>> root account (I don't remember the name).
>>
>> Yup, I see it. Here it is.
>>
>> admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
>>
>> OK, r2793 is the Interpreter VM and it's installed in both boxes. It's
>> installed in a different location that Cog:
>>
>>>> /usr/lib/squeak/4.0-2776
>>>> /usr/local/lib/squeak/4.10.2-2793
>>
>> To my mind that means there's no naming conflict, but I suspect that's not
>> what you mean. In both box3 and box4 the only script in /usr/bin is cogvm
>> in box4. The interpreter VM has no script to start it, which I think
>> explains why "squeak -version" produces nothing at all; whereas, "cogvm
>> -version" does. And this is the naming convention you want to clear with
>> Eliot, right? What to call the script that starts a VM process? I don't
>> think the Interpreter has one installed on either box.
>>
>> Closer?
>>
>> Chris
>>
>>
>>> Dave
>>>
>>>> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to
>>>> upgrade
>>>> box4 to the latest Cog (non-Spur) VM available.
>>>> I think I can do that in box4 with no fuss, as I don't think the
>>>> Interpreter VM is installed. So I don't expect a conflict. It is worth
>>>> noting that some binaries are stored in /usr/local/lib and others in
>>>> /usr/lib.
>>>>
>>>> About where to put the .deb files. I guess the proper thing is to use
>>>> cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>>>>
>>>> Chris
>>>>
>>>>
>>>> [1]
>>>>
>>>> BOX3 - start script used
>>>>
>>>> TEST FOR VERSION:
>>>> cogvm -version r2776
>>>>
>>>> /usr/bin/cogvm
>>>>
>>>> BINARIES AVAILABLE:
>>>> /usr/lib/squeak/4.0-2776
>>>> /usr/local/lib/squeak/4.10.2-2793
>>>> /home/chrismuller/vm/lib/squeak/4.0-2761
>>>> /home/chrismuller/vm/lib/4.4.7-2357
>>>>
>>>> localdebs:
>>>> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
>>>> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
>>>> squeak-sources_4.1-1_all.deb
>>>>
>>>>
>>>> BOX3 - no start script used?
>>>>
>>>> TEST FOR VERSION:
>>>> squeak -version
>>>> cannot find VM to run image 'squeak' with option ''
>>>>
>>>> BINARIES AVAILABLE:
>>>> /usr/local/lib/squeak/4.10.2-2793/squeakvm
>>>> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
>>>> /var/lib/jenkins/jobs/*
>>>>
>>>>
>>>> localdebs:
>>>> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
>>>
>>>
>>>
>>
>
>
>

Eliot Miranda-2

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Bert Freudenberg

On Wed, Jul 2, 2014 at 12:02 PM, Bert Freudenberg <[hidden email]> wrote:

On 02.07.2014, at 18:59, Tobias Pape <[hidden email]> wrote:

> Just that it is not lost,
>
> debian provides a facility to provide normally incompatible
> binaries. (eg, different versions, different vendors)
> they call it alternatives. (See /etc/alternatives)
>
> one example: jvm. or cc.
> on my server:
>
> $ ls -l /usr/bin/cc
> lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
>
> $ ls -l /etc/alternatives/cc
> lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
>
> and you can select:
> $ upate-alternatives --list cc
> /usr/bin/gcc
> /usr/bin/clang
>
>
> That way, we could provide different squeakvm's via this tool :)

Nope. That would work only if all VMs could open all images.

But there's no technical reason why, on linux, we couldn't implement a replacement for the squeak script that would select a different lib dir depending on the type of the image. Perhaps when we have a CI server successfully building all VMs we could afford to do this?

best,

Eliot

Eliot Miranda-2

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by David T. Lewis

On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis <[hidden email]> wrote:

The script is installed as /usr/local/bin/squeak.

Yes that is the one that might get stepped on by the Cog install.

What cog install is this? The Cog tarballs on my site don't install anywhere specific. They unpack to a directory called e.g. coglinuxht, cogspurlinux, etc. They don't stomp on anything.

>From a Debian packaging point of view, there may be other overlapping
files also.

Dave

>
> On Jul 2, 2014, at 12:32 PM, David T. Lewis <[hidden email]> wrote:
>
>> The interpreter VM is installed on both box3 and box4. The debs are in
>> /root/localdebs and a record of the installation is in the log file in
>> the
>> root account (I don't remember the name).
>
> Yup, I see it. Here it is.
>
> admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
>
> OK, r2793 is the Interpreter VM and it's installed in both boxes. It's
> installed in a different location that Cog:
>
>>> /usr/lib/squeak/4.0-2776
>>> /usr/local/lib/squeak/4.10.2-2793
>
> To my mind that means there's no naming conflict, but I suspect that's not
> what you mean. In both box3 and box4 the only script in /usr/bin is cogvm
> in box4. The interpreter VM has no script to start it, which I think
> explains why "squeak -version" produces nothing at all; whereas, "cogvm
> -version" does. And this is the naming convention you want to clear with
> Eliot, right? What to call the script that starts a VM process? I don't
> think the Interpreter has one installed on either box.
>
> Closer?
>
> Chris
>
>
>> Dave
>>
>>> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to
>>> upgrade
>>> box4 to the latest Cog (non-Spur) VM available.
>>> I think I can do that in box4 with no fuss, as I don't think the
>>> Interpreter VM is installed. So I don't expect a conflict. It is worth
>>> noting that some binaries are stored in /usr/local/lib and others in
>>> /usr/lib.
>>>
>>> About where to put the .deb files. I guess the proper thing is to use
>>> cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>>>
>>> Chris
>>>
>>>
>>> [1]
>>>
>>> BOX3 - start script used
>>>
>>> TEST FOR VERSION:
>>> cogvm -version r2776
>>>
>>> /usr/bin/cogvm
>>>
>>> BINARIES AVAILABLE:
>>> /usr/lib/squeak/4.0-2776
>>> /usr/local/lib/squeak/4.10.2-2793
>>> /home/chrismuller/vm/lib/squeak/4.0-2761
>>> /home/chrismuller/vm/lib/4.4.7-2357
>>>
>>> localdebs:
>>> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
>>> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
>>> squeak-sources_4.1-1_all.deb
>>>
>>>
>>> BOX3 - no start script used?
>>>
>>> TEST FOR VERSION:
>>> squeak -version
>>> cannot find VM to run image 'squeak' with option ''
>>>
>>> BINARIES AVAILABLE:
>>> /usr/local/lib/squeak/4.10.2-2793/squeakvm
>>> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
>>> /var/lib/jenkins/jobs/*
>>>
>>>
>>> localdebs:
>>> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
>>
>>
>>
>

--
best,

Eliot

Chris Cunnington-4

Re: [Box-Admins] Updating VMs and possible conflicts

On Jul 2, 2014, at 3:36 PM, Eliot Miranda <[hidden email]> wrote:

On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis <[hidden email]> wrote:
The script is installed as /usr/local/bin/squeak.

Yes that is the one that might get stepped on by the Cog install.

What cog install is this? The Cog tarballs on my site don't install anywhere specific. They unpack to a directory called e.g. coglinuxht, cogspurlinux, etc. They don't stomp on anything.

I think that's the point entire. Ken chose one place to install Cog /usr/bin/squeak while David chose to install the Interpreter in /usr/local/bin/squeak. They each built their debs (and deb creation tools like cogdeb.zip) differently. Probably by accident. Perhaps that's a good thing?

Chris

>From a Debian packaging point of view, there may be other overlapping
files also.

Dave

>
> On Jul 2, 2014, at 12:32 PM, David T. Lewis <[hidden email]> wrote:
>
>> The interpreter VM is installed on both box3 and box4. The debs are in
>> /root/localdebs and a record of the installation is in the log file in
>> the
>> root account (I don't remember the name).
>
> Yup, I see it. Here it is.
>
> admin-log.txt: sudo dpkg -i /root/localbuild/squeakvm_20131020-1_i386.deb
>
> OK, r2793 is the Interpreter VM and it's installed in both boxes. It's
> installed in a different location that Cog:
>
>>> /usr/lib/squeak/4.0-2776
>>> /usr/local/lib/squeak/4.10.2-2793
>
> To my mind that means there's no naming conflict, but I suspect that's not
> what you mean. In both box3 and box4 the only script in /usr/bin is cogvm
> in box4. The interpreter VM has no script to start it, which I think
> explains why "squeak -version" produces nothing at all; whereas, "cogvm
> -version" does. And this is the naming convention you want to clear with
> Eliot, right? What to call the script that starts a VM process? I don't
> think the Interpreter has one installed on either box.
>
> Closer?
>
> Chris
>
>
>> Dave
>>
>>> I did a bit of a survey of VMs on boxes 3 and 4. [1] My aim is to
>>> upgrade
>>> box4 to the latest Cog (non-Spur) VM available.
>>> I think I can do that in box4 with no fuss, as I don't think the
>>> Interpreter VM is installed. So I don't expect a conflict. It is worth
>>> noting that some binaries are stored in /usr/local/lib and others in
>>> /usr/lib.
>>>
>>> About where to put the .deb files. I guess the proper thing is to use
>>> cogdeb.zip in /root/localbuild and then copy the deb to /root/localdeb.
>>>
>>> Chris
>>>
>>>
>>> [1]
>>>
>>> BOX3 - start script used
>>>
>>> TEST FOR VERSION:
>>> cogvm -version r2776
>>>
>>> /usr/bin/cogvm
>>>
>>> BINARIES AVAILABLE:
>>> /usr/lib/squeak/4.0-2776
>>> /usr/local/lib/squeak/4.10.2-2793
>>> /home/chrismuller/vm/lib/squeak/4.0-2761
>>> /home/chrismuller/vm/lib/4.4.7-2357
>>>
>>> localdebs:
>>> cogvm_2776-1_i386.deb squeakvm_20131020-1_i386.deb
>>> djbdns_1.05-2_amd64.deb squeakvm64_20131020-1_i386.deb
>>> squeak-sources_4.1-1_all.deb
>>>
>>>
>>> BOX3 - no start script used?
>>>
>>> TEST FOR VERSION:
>>> squeak -version
>>> cannot find VM to run image 'squeak' with option ''
>>>
>>> BINARIES AVAILABLE:
>>> /usr/local/lib/squeak/4.10.2-2793/squeakvm
>>> /home/davidlewis/[VM|VMCogUnixBuild|VMUnixBuild]
>>> /var/lib/jenkins/jobs/*
>>>
>>>
>>> localdebs:
>>> squeakvm_20131020-1_i386.deb squeakvm64_20131020-1_i386.deb
>>
>>
>>
>

--
best,
Eliot

Bert Freudenberg

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Eliot Miranda-2

On 02.07.2014, at 21:35, Eliot Miranda <[hidden email]> wrote:

On Wed, Jul 2, 2014 at 12:02 PM, Bert Freudenberg <[hidden email]> wrote:

On 02.07.2014, at 18:59, Tobias Pape <[hidden email]> wrote:

> Just that it is not lost,
>
> debian provides a facility to provide normally incompatible
> binaries. (eg, different versions, different vendors)
> they call it alternatives. (See /etc/alternatives)
>
> one example: jvm. or cc.
> on my server:
>
> $ ls -l /usr/bin/cc
> lrwxrwxrwx 1 root root 20 Mar 19 13:10 /usr/bin/cc -> /etc/alternatives/cc
>
> $ ls -l /etc/alternatives/cc
> lrwxrwxrwx 1 root root 12 Mar 19 13:10 /etc/alternatives/cc -> /usr/bin/gcc
>
> and you can select:
> $ upate-alternatives --list cc
> /usr/bin/gcc
> /usr/bin/clang
>
>
> That way, we could provide different squeakvm's via this tool :)

Nope. That would work only if all VMs could open all images.

But there's no technical reason why, on linux, we couldn't implement a replacement for the squeak script that would select a different lib dir depending on the type of the image.

Yep, that's the way to go. I was just pointing out that the alternatives mechanism isn't intelligent enough for this.

- Bert -

smime.p7s (5K) Download Attachment

David T. Lewis

Re: [Box-Admins] Updating VMs and possible conflicts

In reply to this post by Eliot Miranda-2

On Wed, Jul 02, 2014 at 12:36:15PM -0700, Eliot Miranda wrote:
> On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis <[hidden email]> wrote:
>
> > The script is installed as /usr/local/bin/squeak.
> >
> > Yes that is the one that might get stepped on by the Cog install.
> >
> What cog install is this? The Cog tarballs on my site don't install
> anywhere specific. They unpack to a directory called e.g. coglinuxht,
> cogspurlinux, etc. They don't stomp on anything.

The squeakvm interpreter VM is typically installed in /usr/local/, so the
start script is /usr/local/bin/squeak. This has been the case for the last
15 years or so.

If a unix/linux installs Cog, they will typically want to install it in
/usr/local/. In that case, the Cog start script stomps on the squeakvm
start script.

The same issue exists for installation in /usr/ as opposed to /usr/local/.

Dave

Eliot Miranda-2

Re: [Box-Admins] Updating VMs and possible conflicts

On Wed, Jul 2, 2014 at 5:24 PM, David T. Lewis <[hidden email]> wrote:

On Wed, Jul 02, 2014 at 12:36:15PM -0700, Eliot Miranda wrote:
> On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis <[hidden email]> wrote:
>
> > The script is installed as /usr/local/bin/squeak.
> >
> > Yes that is the one that might get stepped on by the Cog install.
> >
> What cog install is this? The Cog tarballs on my site don't install
> anywhere specific. They unpack to a directory called e.g. coglinuxht,
> cogspurlinux, etc. They don't stomp on anything.

The squeakvm interpreter VM is typically installed in /usr/local/, so the
start script is /usr/local/bin/squeak. This has been the case for the last
15 years or so.

If a unix/linux installs Cog, they will typically want to install it in
/usr/local/. In that case, the Cog start script stomps on the squeakvm
start script.

No it doesn't. Look at the tarballs. They expand to a local directory called coglinux, et al. Further, their squeak scripts are cntained in that directory hierarchy. What you describe would only happen if one did a build of a Cog VM and told the configure script to install in /usr/local. Note that my build scripts dont do this. They "install" to a staging directory in which the tarballs are made.

The same issue exists for installation in /usr/ as opposed to /usr/local/.

Dave

I don't agree. I don't see how one could do this inadvertently at all.

--
best,

Eliot

David T. Lewis

Re: [Box-Admins] Updating VMs and possible conflicts

On Wed, Jul 02, 2014 at 07:03:05PM -0700, Eliot Miranda wrote:

> On Wed, Jul 2, 2014 at 5:24 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Wed, Jul 02, 2014 at 12:36:15PM -0700, Eliot Miranda wrote:
> > > On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis <[hidden email]>
> > wrote:
> > >
> > > > The script is installed as /usr/local/bin/squeak.
> > > >
> > > > Yes that is the one that might get stepped on by the Cog install.
> > > >
> > > What cog install is this? The Cog tarballs on my site don't install
> > > anywhere specific. They unpack to a directory called e.g. coglinuxht,
> > > cogspurlinux, etc. They don't stomp on anything.
> >
> > The squeakvm interpreter VM is typically installed in /usr/local/, so the
> > start script is /usr/local/bin/squeak. This has been the case for the last
> > 15 years or so.
> >
> > If a unix/linux installs Cog, they will typically want to install it in
> > /usr/local/. In that case, the Cog start script stomps on the squeakvm
> > start script.
> >
>
> No it doesn't. Look at the tarballs. They expand to a local directory
> called coglinux, et al. Further, their squeak scripts are cntained in that
> directory hierarchy. What you describe would only happen if one did a
> build of a Cog VM and told the configure script to install in /usr/local.
> Note that my build scripts dont do this. They "install" to a staging
> directory in which the tarballs are made.

I am familiar with the tarballs. There is nothing wrong with them.

This discussion is about installing a Cog VM in one of the usual expected
places for a Unix or Linux system, as opposed to running it from a directory
e.g. in the user's home directory.

Users expect packages to be installed in familiar places, and package
managers expect packages to not stomp on one another in the installation
process.

Those expectations are not difficult to meet. For example, if the traditional
Squeak VM is known to be started with a shell script called "squeak", and if
that script is known to be installed typically in /usr/bin/ or /usr/local/bin/,
then it's not hard to antipate that using the same name for the start script
for Cog and/or Spur is likely to lead to conflicts. But if you give the start
script a different name, such as "cog" or "spur" or "cogvm" or "spurvm", then
there is no problem.

This is no different from Interpreter and StackInterpreter. The two are different,
so when installed in the same image, you have given them different names. Do
the same thing for your start scripts, and all will be well.

Dave