José Luis Redrejo wrote:
> 
> 
> 2009/4/20 Matej Kosik <kosik at fiit.stuba.sk <mailto:kosik at fiit.stuba.sk>>
> 
>     José Luis Redrejo wrote:
>     >
>     >
>     > 2009/4/20 Matej Kosik <kosik at fiit.stuba.sk
>     <mailto:kosik at fiit.stuba.sk> <mailto:kosik at fiit.stuba.sk
>     <mailto:kosik at fiit.stuba.sk>>>
>     >
>     >     Bert Freudenberg wrote:
>     >     >
>     >     > On 19.04.2009, at 23:57, Matej Kosik wrote:
>     >     >
>     >     >> Bert Freudenberg wrote:
>     >     >>>
>     >     >>> On 19.04.2009, at 22:20, Matej Kosik wrote:
>     >     >>>>
>     >     >>>> Are there any versions of Squeak images that could be
>     imported to
>     >     >>>> Debian
>     >     >>>> repositories? (some minimal images with sorted out licencing
>     >     issues).
>     >     >>>
>     >     >>>
>     >     >>> Not exactly minimal, but license-clean:
>     >     >>>
>     >     >>> http://download.sugarlabs.org/sources/sucrose/glucose/etoys/
>     >     >>
>     >     >> I have looked at it (btw. Jose already created and registered
>     >     >> appropriate package---cool). Is it possible to somehow open a
>     >     browser,
>     >     >> workspace and such? (in that image)?
>     >     >
>     >     > It's not really meant for Smalltalk development, but you can
>     press
>     >     > alt-shift-w to get the full world menu.
>     >
>     >     The two images:
>     >     - etoys
>     >     - etoys-dev
>     >     would fit to the Lex's scheme
>     >     http://ftp.squeak.org/debian/squeak-on-debian.pdf
>     >     I think, that whatever Jose wanted to achieve with his separate
>     >     squeak-vm package can be achieved also with our squeak-vm
>     package (now
>     >     they are different).
>     >
>     >     What would be the advantage?
>     >     - We could keep our rich repository:
>     >      http://wiki.squeak.org/squeak/3616
>     >      That contains also "licence unclean" packages.
>     >     - Some of those packages could be posted to Debian
>     >      - etoys
>     >      - etoys-dev
>     >      Really, people could then:
>     >
>     >            apt-get install etoys
>     >
>     >      and run it as:
>     >
>     >            etoys
>     >
>     >     - We would not have to maintain two (three, four, ...)
>     >      separate squeak-vm package versions.
>     >
>     >     How does this sound to Lex and especially to Jose?
>     >
>     >
>     >
>     > I'm afraid I don't understand what you mean.
> 
>     Having two separate squeak-vm packages (yours and ours) is, by default,
>     a nonsense. Unless there is a reason for it. Is there a reason?
> 
>     Cannot we create a single squeak-vm package that would work both, for
>     you (etoys) and for us (packages published on Squeak wiki)?
> 
> 
> 
> The package currently in Debian should work with the image packages
> published on Squeak wiki. I've not tested it, but as far as I know,  you
> use the same directories as I use, they work.

I am going to analyze look at the incompatibilities.

>  
> 
> 
>     Are our goals (concerning what squeak-vm package should provide)
>     mutually exclusive?
> 
>     Squeak-vm package must be maintained by someone, who actually also
>     understands the source code and can solve possible minor problems. I am
>     not such a person.
> 
>     I could ask in another way: cannot your goals be achieved by taking our
>     squeak-vm package and updating it? If not, why?
> 
> 
> Not, because:
> a) your package doesn't have desktop integration

I would restated this statement as "desktop integration of our package
can be improved".

> b) your package is developer friendly, not user friendly. A terminal is
> needed to choose between the installed images.

Is this an inherent problem why our squeak-vm should be discarded? I
think it can be fixed. I haven't studied KDE and GNOME specific menu
systems, I confirm. On the other hand, we support debian-menu system
(supported by all the other window managers except for KDE and GNOME).

> The package in Debian
> show a zenity dialog (I've also added a kdialog if kde is used, but not
> uploaded that change to Debian yet) to choose the images, so the user
> doesn't need to launch a terminal and write some unix commands to get
> the image loaded.
> c) your package compiles the MPEG3Plugin that can not be in Debian due
> to patents problems.

Is this an inherent problem why our squeak-vm should be discarded?

> d) If you take a look at
> http://packages.debian.org/changelogs/pool/main/s/squeak-vm/squeak-vm_3.10.3+svn1902.dfsg-1/changelog
> you can also see that I have added some patches to fix bugs that were
> not fixed in the official sources when I did the package. Most of them
> are fixed updtream today

You are doing a good job (as far as I can tell).

> 
> 
> 
> Maybe, the question can be: cannot your goals be achieved by taking the
> squeak-vm package available in Debian? if not, why?

I have never asked this question myself because we always have Debian
packages around so there were exactly zero reasons why to look for
something else (from my point of view). If I wanted to express
impolitely (logically) I would say---competing alternatives to already
estabilished solutions have to justify their existence. Not what is
already estabilished. Novelty does not automatically give this
justification. I hope you will not be angry for all this disturbance.
Email is not ideal medium for discussions (mainly when it comes to
guessing emotions).

> Please, don't misunderstand me, I'm totally open to change the package ,
> but points a) and b) are really important for me. While the squeak.org
> <http://squeak.org> package doesn't have those features, I'm not going
> to take backwards my users.

What I believe is, that points a) and b) can be fixed in squeak.org
packages. The reason why they were not fixed is, because I, for example,
reject studying random standards. On the other hand, I am not against if
someone (you) actually ensures that those standards are followed.

> Point c) is a must inside Debian.

This problem is unintentional at our side. I believe, it could be as
easily fixed on our side as you fixed it at your side.

>From technical point of view, what you have listed are minor details.
(on the other hand, details make the difference). I see them as
additional featuers not incompatible with what we already have.

I will now try to look at incompatibilities which---if we decided to
merge (regardless whose squeak-vm package will be taken as a base)
should be resolved---things we do differently and one of us should
change the mind in favor of the merge. I will let you know.

Best regards,
--
Matej Kosik