(Sorry, this is going to be a longer post, covering a lot of basics, but I feel even most Linux Squeakers are unaware of how open-source software actually gets to users in Linux)

On 15.04.2009, at 09:05, Jerome Peace wrote:

Chris Kassopulo ckasso at sprynet.com Tue Apr 14 02:00:01 UTC 2009 wrote:

...

I was told via bug report that Ubuntu doesn't support OSS at all.

It is the opposite of what you are trying to do but on my Ubuntu box, I removed the Ubuntu squeak related packages and installed the DEB squeak-vm package. I can open squeak and etoys images with the command: squeak /path_to_image/image_name.image and sound works.

Atually this sounds like it is on the path to a solution.

Can we get a DEB package that we can offer from the website in such a way that when Ubuntu goes searching for a squeak to install it installs that vm?

Bert: That that sound like the way to go?

Not really, that would just be a workaround.

In the closed-source world (Mac, Win) typically the software authors provide binary packages for end users. This is even true for open- source software on these platforms, the authors provide ready-to- install packages, separate from with the source code. That's why we have Windows and Mac downloads on our website. It's a one-size-fits- all approach, and all work is done by the authors.

Not so in Linux. Here, building the binary packages that fit into a specific Linux distribution is typically done by users of that Linux version. These volunteers ("package maintainers") take the source code from an "upstream" author and make a binary package from that, typically by writing a few scripts that compile and install the software in the right place and with the right supporting files (which may be different for each Linux distribution).

Because of these volunteers it is that you can simply install about *any* free software from your distro's "software installer". Every single one of these thousands of packages was added and is maintained by someone.

As you can guess, package maintainers are usually no experts in the software they package. They will try the canonical "./configure; make; make install" command, and if that appears to work they make a package from that, do a few tweaks maybe and release it. People can install that package easily now, and everything appears to be fine.

Except it's not. E.g., unless the package builder declared a build- dependency on the "alsa-lib-devel" package (that's what it is called in Fedora anyway) the Squeak VM will be built without ALSA sound support. The "configure" script is smart enough to not build the "vm- sound-ALSA" plugin if it does not find the necessary files. It also writes out a message that the plugin was disabled. But that is easy to overlook, and also not fatal - there are good reasons for not wanting to build that plugin.

Now what needs to happen is that a user who discovers that sound is not working must file a bug report for the package *maintainer*. Not with the author (us), because that would bypass the maintainer. So use your distro's bug tracker, not bugs.squeak.org. The maintainer either fixes the problem, or opens an "upstream" bug with the authors. Sometimes it's even a chain of "upstreams", in Ubuntu's case the package may come from Debian, so a user would file a report at Ubuntu's tracker, the Ubuntu maintainer at Debian's tracker, and the Debian maintainer with us.

If instead we bypass the maintainers, we get precisely the chicken-and- egg problem we are in now. The distro packages do not work well, so the experienced developers do not use them but compile their own. Which leaves the packages in their bad state because nobody knowledgeable cares about them.

To be fair, in the "sound on Ubuntu" case in fact the proper procedure was followed: https://bugs.launchpad.net/ubuntu/+source/squeak-vm/+bug/235146 but apparently did not get fully resolved yet. Not sure what needs to happen next in this specific case.

But in general, we should try to make it as easy for package maintainers as possible. Even if it is just by letting them know that their package is used. So Squeak developers on Linux should try to use the distro's packages, and if they are insufficient, give feedback. Also, the source code should come with clear instructions on how to build it, what dependencies there are etc.

Maybe having a mailing list specifically for maintainers would be useful? But even just tracking down what packages are already out there, who is maintaining them etc. would be very valuable. And monitoring the bug trackers, participating on the distro-maintainers lists etc. Here is just a short list for squeak packages in various distros:

Debian: http://packages.debian.org/search?keywords=squeak-vm Fedora: https://admin.fedoraproject.org/pkgdb/packages/name/squeak-vm Ubuntu: https://launchpad.net/ubuntu/+source/squeak-vm OpenSuSE: http://download.opensuse.org/repositories/devel:/languages:/smalltalk/openSU... Gentoo: http://gentoo-portage.com/dev-lang/squeak Arch: http://aur.archlinux.org/packages.php?ID=13021

The good news is that once there are "good" packages in the major Linux distributions, the smaller ones can follow suite much more easily. The big issues of e.g. what build dependencies exist are solved by then, and everyone can learn from each other.

Squeakers have been pretty much ignorant of the larger open-source community in the past. But I think there is a lot to be gained by becoming a proper part of it. I have been working towards that goal for a while now, in particular as part of the OLPC / Sugar development efforts. Etoys is distributed as part of Sugar and depends on an up-to- date Squeak-VM package, so we do have allies in the Sugar maintainers. And everyone can help - as I wrote above, no deep VM knowledge is necessary to monitor bug trackers or keep contact with the maintainers.

So there. Who else wants to get involved?

- Bert -

PS: Note that I am primarily concerned with the VM packages for now. Packaging images is a somewhat separate issue, simpler because no dependencies are involved, and at the same time harder because there is no established practice of where to put them in the file system hierarchy. There used to be the license issue with images, too, but we should shoot for proper packaging with the license-clean upcoming 4.0 release. If you want to discuss this, please start a different thread.