On Tue, Dec 6, 2011 at 9:38 PM, Eliot Miranda
<eliot.miranda@gmail.com> wrote:
On Tue, Dec 6, 2011 at 11:05 AM, Pavel Krivanek
<pavel.krivanek@gmail.com> wrote:
Hi,
I want make a little report about progress with making of Fedora
pakcages for Smalltalk related projects (StackVM, CogVM, Pharo...) by
Jaroslav ��karvada.
Currently there are three packages in Fedora repositories - squeak-vm,
squeak-image and squeak-vm-nonXOplugins (that contains plugins like
OSProcess). It uses resources from the Squeak site.
Red Hat has quite restrictive demands on packages and it is a small
miracle that they tolerate current squeak packages :-). The conditions
simply do expect that a program is a set of source codes and not a
system of communicating objects. One problem is that Squeak VM is one
of few metacircular packages that are needed for their own building.
Because binary executables are prohibited, it would require a special
bureaucratically problematic exception. Fortunately for virtual
machine generation we may use the current squeak packages - more
precisely their updated versions. The next issue for virtual machine
generation may be the fact, that some packages used for VM generation
are in repositories with public read&write permissions.
Because image can be likened to *.jar files that are prohibited and
must be recompiled during package generation, we are lucky that
squeak-image package is currently accepted. If someone starts
tinkering, we are in big trouble.
There is a little issue with *.sources placement. The current VM
package contains symlinks from VM path to sources files that are
present in package with the image. This is really ugly solution.
Squeak and Pharo uses this sequence for sources lookup: vm path, image
path, current path. So I think that the best solution will be to have
sources file in the image package, do not have symlinks in vm package
and to create symlink to sources together with changes in the image
path via mysqueak initialization script.
Btw., Jaroslav told me that he saw a lot of creepy projects but
nothing like Squeak VM :-)
And there is a mess in VM versioning. What is the latest CogVM/StackVM
version number?
But where is such information stored?
Then, the VMMaker package version says nothing, because to buiyld the VM you need more packages than VMMaker, so you have to guess which version to use.
Moreoever, there is also ANOTHER version in VM which is VMMaker class>>versionString�� which is different from that.
Then from the image or from a log we get: VM: Mac OS - intel - 1068 - Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.78] Croquet Cog 3.0.0
so where it is the svn version?
So...all in all, I think that indeed, it is quite a mess. But it is also complicated to manage and I don't really know what to suggest.
With ConfigurationOfCog at least with one number we group all image side related packages.
Then we only need svn/git version. Moreover, we can store this svn/git as the description in each version of ConfigurationOfCog. That way, you know *exactly* what do you need.��
Cheers
��
--
best,Eliot