Hi all,

Jerome Peace wrote:
> [squeak-dev] Re: Ubuntu package maintainers help
> 
> Hi Matej,
> 
> Looking at your dependency chart I see that there is now a language clash.
> 
> We need to disambiguate what is meant by squeak-plugin.
> 
> The word plugin is used to mean both 
> sqeuak-browser-plugin which is a dingus that adds functionality to an external browser. 
> 
> 
> 
> and 
> squeak-internal-plugins which are pieces that add functionality or speed to squeak itself.
> 
> those plugins are 
> things like vm-sound-ALSA which when missing caused the sound problem on Ubuntu.
> 
> Most of the time those plugins are in a default path and there is no need to mention them.
> For etoys the default path plugins are in the same place as the vm itself.
> 
> For the ubuntu squeak the plugins are in a separate directory than the vm and the shell just happens to know where that is.
> 
> To add to the merry confusion. There are vmplugins to make the squeak-browser-plugin work. These are in the vmplugin directory with and np... prefix.
> 
> On Ubuntu the sqeuak-plugin package is considered different than the squeak package.
> 
> The squeak-plugin package may also refer to a particular image. Maybe there is something special a squeak needs to do if being run in a browser.
> 
> Murkier and murkier.
> 
> =====
> Howerer when I am trying to describe a problem that concerns them the other meaning of the word plugin confuses things a lot.
> 
> So we need to find and use a consistent language that allows us to distinguish between the browser plugin and a vm extention plugin. Particularly for the benifit of external packagers.
> 
> Jose: how do you deal with this? How do we disambiguate the two meanings?
> 
> Yours in curiosity and service, --Jerome Peace

The package with the name `squeak-plugin' in my case means the
web-brower plugin. Its meaning is disambiguated on two places:
- the package description itself states that it is a web-browser plugin
- the wiki page:
  http://wiki.squeak.org/squeak/3616
  also states that.
So, I hoped that users have enough information to determine what
services this package offers.

Developers (who know also that there are internal and external plugins),
I hope, will have even less problems to disambiguate.

If my assumptions are wrong, the package name can be changed.

I do not see this as a major problem. Major problem is, if we agree with
Jose on merging of our separate forks of packages. If we merge them, we
can also concentrate on things we are interested in (he is interested in
Etoys, we are interested to a rich set of images) and we can share work
that we have in common---maintenance of the squeak-vm package.