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
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
On Jul 2, 2014, at 12:32 PM, David T. Lewis lewis@mail.msen.com 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
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 lewis@mail.msen.com 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
On Jul 2, 2014, at 3:04 PM, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com 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
On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com 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
On Jul 2, 2014, at 3:36 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Jul 2, 2014 at 12:04 PM, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com 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
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 lewis@mail.msen.com 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
On Wed, Jul 2, 2014 at 5:24 PM, David T. Lewis lewis@mail.msen.com 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 lewis@mail.msen.com
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.
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 lewis@mail.msen.com 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 lewis@mail.msen.com
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
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 brasspen@gmail.com 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
On Jul 2, 2014, at 12:59 PM, Tobias Pape Das.Linux@gmx.de 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 brasspen@gmail.com 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
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de 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.
- Bert -
On 02.07.2014, at 21:02, Bert Freudenberg bert@freudenbergs.de wrote:
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de 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
On 02.07.2014, at 21:03, Tobias Pape Das.Linux@gmx.de wrote:
On 02.07.2014, at 21:02, Bert Freudenberg bert@freudenbergs.de wrote:
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de 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 -
On Wed, Jul 2, 2014 at 12:02 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de 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
On 02.07.2014, at 21:35, Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Jul 2, 2014 at 12:02 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 02.07.2014, at 18:59, Tobias Pape Das.Linux@gmx.de 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 -
squeak-dev@lists.squeakfoundation.org