[squeak-dev] Re: Unix updates

José Luis Redrejo jredrejo at gmail.com
Wed Dec 16 18:17:50 UTC 2009


2009/12/16 Andreas Raab <andreas.raab at gmx.de>

> Hi -
>
> I think I'll stand back from this discussion. It's clear that I don't
> understand the constraints on Linux and that I'm pushing directions that are
> not appropriate. I would like to see the ability for new users on Linux to
> get to the latest versions though; if there's anything we can do to make
> this happen, please let us know.
>
> Cheers,
>  - Andreas
>
>
>

Hi Andreas, from my experience as Debian maintainer of both: etoys and
squeak-vm, what I've mainly missed is:

a) help with the issues in non 32 bits platforms
b) collaboration with the people who package the vm in squeak.org
c) help with the issues with the Squeak license

For a): adding new plugins needed by the etoys image (RomePlugin,
GstreamerPlugin) is great when the plugin can be compiled, but it's only
tested in a 32 bits platform, and doesn't use to follow the gnu/autotools
standards that most unix applications use. As a result: it doesn't work in
other platforms, specially important are the problems in amd64. Ian Piumarta
fixed the problems the vm had in 64 bits, but whenever a new plugin is
added, new bugs are added, and Ian is not responsible of every plugin. The
bugs I added to mantis have stayed there for years.

For b): there were some discussions in this list. As result of them I
created a group in alioth.debian.org to work together, I offered all my help
and nobody has added a line of code.

For c): I don't think I need to explain anything about the license. I "met"
Squeak on 2003, and the steps to get a "free" image begun on 2007, four
years after being asking/trying a solution. Anyway, Squeak development is so
"weird" in the software world that I don't think the final problems will
ever solved: bootstraping an image from sources, or have any way to
demonstrate (working from the OS, not inside Squeak) that the image contains
only free code.


c) causes etoys to be in the non-free section of Debian

b) has caused the current delay in Debian, because I've been waiting for  6
months, just in case anybody wants to help. I've already given up, so I will
upload the latest version before the end of this month. Before the setting
up of the collaborative project I kept the squeak-vm very updated in Debian.
In fact  I used to compile it from svn, to get the latest patches, trying to
make the images work with the newest plugins. But, even when the image was
the same in Debian than in squeak.org, and the vm was in Debian newer and
more polished than the one in squeak.org, I always saw how
squeak.orgdocumentation  recommended for Debian (and derivatives)
users installing the
packages avoiding to use the standard way in the distribution, and making it
almost impossible to use for a non-experienced user in Linux.

a) is still causing me headaches when the users fill bugs and ask for help.

My 20 cents

Regards
José L.



Bert Freudenberg wrote:
>
>> On 16.12.2009, at 15:20, Andreas Raab wrote:
>>
>>> Bert Freudenberg wrote:
>>>
>>>> And then what?
>>>>
>>> How the heck do I know? ;-) But you are sounding self-contradicting here.
>>> This discussion started with you pointing out that you wouldn't expect to
>>> find anything current in the package management system of choice.
>>>
>>
>> I don't think I started the discussion this time, but it's true
>> nonetheless, for now. But the solution IMHO is not ignoring the distro
>> packages. Downloading from squeak.org should become only the second-best
>> option after the one expected by Linux users.
>>
>>  As a consequence I've been trying to find some ways by which we could get
>>> users the information that there's something more up to date.
>>>
>>
>> Appreciated. But I don't think the primary problem is that people are
>> unaware of newer versions, but that getting a current Squeak is harder than
>> usual for Linux software.
>>
>>  But now you're saying leave it to the distro maintainers? Isn't that
>>> directly contradicting your initial statement? If we assume that the
>>> packages are generally current, then there's no point whatsoever to this
>>> entire discussion (which started by Igor pointing out that current packages
>>> are *not* current).
>>>
>>> Confused,
>>>  - Andreas
>>>
>>
>> I'm looking for ways to actually fix this, not for more workarounds. And
>> what we do as interim solution should not interfere with the proper way.
>>
>> So IMHO it is good if we provide a tarball on squeak.org for those who
>> like to install manually (though IMHO it should include an image, not like
>> the one currently linked on the homepage).
>>
>> And we should at least not do anything that undermines the efforts of
>> packagers, instead encouraging use of the distro packages. If nobody uses
>> them they won't get fixed. So next time someone notices a problem with a
>> distro package *please* file a bug report in the distro's tracker.
>>
>> - Bert -
>>
>>  Linux has advanced beyond "./configure; make; make install". Downloading
>>>> a tarball feels antiquated. Regular users don't do that anymore unless they
>>>> absolutely have to. Package maintainers do and bundle this in a package for
>>>> their distro.
>>>> Even downloading a DEB or RPM from random web sites doesn't make it much
>>>> better, because this interferes with distro packages, again bypassing the
>>>> official update mechanism.
>>>> IMHO the debs and rpms on squeak.org should be removed, and maintenance
>>>> moved to the respective distros. Empower and support the maintainers, like
>>>> Debian's José Redrejo or Fedora's Gavin Romig-Koch or Mandriva's Aleksey
>>>> Lim.
>>>> - Bert -
>>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091216/fbb9f580/attachment.htm


More information about the Squeak-dev mailing list