Thanks for your feedback, Ross!

Ross Boylan <RossBoylan at stanfordalumni.org> wrote:
> Thanks; I've been waiting eagerly.  I have a woody system, and note
> the OSS package says 
> depends: libc6 (>= 2.2.4-4), xlibs (>> 4.1.0)
> 
> Meanwhile, my system has versions
> ii  libc6            2.2.5-3
> ii  xlibs            4.1.0-13
> 
> Although I'm afraid I know the answer, does 4.1.0-13 qualify as >> 4.1.0?

I believe so....  The version numbers were filled in automatically when
the package was built, and surely these tools are doing the right thing.



> 
> By the way, is NAS related to KDE's aRTS?

It's the same kind of system, but NAS is older.  aRTS always overwhelms
me when I try to learn to use it.  esd is insufficient for Squeak, as
far as I can tell.

Frankly, I don't understand why people keep hacking together new audio
servers.  NAS is powerful and well-designed.  It's even in commercial
use: NCD X terminals are NAS-enabled.  You don't see every Unix
distribution writing it's own variation on XWindows -- why write
variations on NAS?


By the way, there is a compatibility path to NAS from OSS, esd, and
artsd, so you can switch to NAs and keep using your other software.   In
short, the "audiooss" program lets you run OSS programs under NAS, and
esd and artsd have OSS versions.  The only problem is programs like
Quake III that want to mmap() the device....



> Is there a reason the packages are in non-US?

Squeak includes cryptography code.  Actually, this is where Stephen
Stafford put it, and I haven't really reconsidered the issue.  Perhaps
it could be moved to main if it's a big deal.

Of course, this discussion is all a little funny since it's an
unofficial package.  I guess we should still try to do the best possible
anyway.  Who knows, maybe the license gets changed before too long,
judging from recent traffic on the list!



> The fact that both the debian packages and smalltalk use "changes" and
> "sources" makes things a bit confusing, but it probably can't be
> helped.

With sources, it's the same meaning: the "squeak-sources3" package gives
you SqueakV3.sources.  There is no "squeak-changes" package, because the
"squeak-image" packages each include the appropriate changes file.  

Admittedly the squeak-3.blahblah-1.changes is a Debian thing unrelated
to Squeak.


> 
> It might be nice to have a note on how you can mix and match the
> different files, though the dependency info captures it pretty well.
> As I understand it:
> 3.2 VM works with any 3.x series images and sources
> 3.2 image requires 3.2 VM (I note the current dependency is not
> versioned, and it probably should be, since not everything works with
> earlier VMS) and 3.0 sources.

Ok.  This should get clearer when:

	1. There is more than one image in there.  :)

	2. This stuff is put in at directory that apt understands, so that the
UI's will help you.  The more I think about it, the more useful this
"little" thing starts to sound.

By the way, I've actually thought through the versioning pretty
carefully, even though it's not noted anywhere.  I'll append my
reasoning at the end of this message.  Among other things, I *don't*
think the VM should have a major version -- a new VM should work with
any older image (or at least, any image within the last couple of years
or so.).  I suppose when the "V4" image comes out, there will be a new
VM version number.  That will be an "interesting" version juggling
problem, but let's give it a little while.



> If you have an existing image you almost certainly do NOT want to
> apply the image update, but update from the squeak server to retain
> your personal stuff.

Hmm, the packages seem to be unclear about this.  The image package just
installs a *canonical* image in /usr/share/squeak.  Users need a copy of
the image and changes file in their own directory.



> Also, a note on the build history (i.e., did the source tarball, in
> the debian sense, come from some intermediate stage of VMMaker, or the
> CVS repository) would be good.  That may be there; I haven't unpacked
> it yet.

Yes, there is a README.Debian in at least the squeak-vm packages.  But
there's nothing to it; basically it points to a Swiki page, which in
turn basically says "CVS plus VMMaker".  Incidentally, the .orig.tar.gz
file is a snapshot that everything was built from before any
Debianization; this might interest non-Debian folks who want to
recompile the VM but don't want to fuss with CVS.

-Lex

==== versioning in the packages =====


First, a definition of all these files.  An image is a snapshot of a
running Smalltalk system.  When you load an image with the virtual
machine, you start up again right where the snapshot was taken.  The
Smalltalk code you have written, however, is not stored in the image,
but in two other files.  First, the sources file holds code common
across a great many images, and is shared.  Second, each image is
associated with a changes file (normally) which holds code specific to
that image.  (It's confusing; there are reasons to do it this way, but
-- it's confusing!!)


The sources file holds code common across very many images --
specifically, SqueakV3.sources holds source code that all 3.x-nnnn
images use.  Every couple of years or so, a new sources file is made,
and it does make sense to have multiple ones installed at the same time.
 Also, by their nature, a new version of a sources file will never be
released.  I made up a -0.0 version, anyway, just to make debhelper
happy.  (And, who knows?!  Funnier things have happened)


The changes file holds code for a particular image.  Thus, there are no
packages for changes files; you get changes files in the appropriate
image package.  Some wierdos might want just the image, but they are
strange and can just deal with losing 15MB or disk space for their
wierdness.


Images have a upstream versions like "3.2-4653".  3.2 is the main
version number, and 4653 is the patchlevel.  I think it makes sense to
have both 3.2-xxxx and 3.3-yyyy installed at the same time, but not a
lot of sense to have two different 3.2-xxxx's installed.  Thus,
squeak-image3.2.

The virtual machine should work on any Squeak image, so I didn't put a
version in the package name.  Whenever the VM fails on an old image
(which it occasionally does), it's considered a bug, and is (ideally)
fixed in future VM versions.

Finally, inisqueak is a script for newbies so that they don't have to
understand all of the above.  I've tweaked it to be versionless, so long
as one of the images installed on the system has been chosen as the
canonical one.