[BUG] MessageNotUnderstood: Error>>downloadFileName when
installing from SqueakMap using script ( [closed] Fixed the
small bug, includes explanation. )
dway at mailcan.com
Mon Jul 19 23:43:15 UTC 2004
On Jul 19, 2004, at 5:43 PM, Bernhard Pieber wrote:
>> Ok, if you don't want to specify a specific release - then the
>> installPackageNamed: would work *iff* there was a published release of
>> "Worlds Of Squeak Removal" that also was marked for Squeak 3.7.
> Well, this illustrates the problem with approaches like this: When a
> release is made all packages are automatically shown as "dangerous" to
> the user even if they work fine. In a way, you get hundreds of false
> positives and need manual intervention of a developer to remove them
> again. And this even for ultra stable packages which were not touched
> since a long time.
> That leads me to the following conclusions: If a package is not marked
> as 3.7 chances are high that it works anyway. OTOH, even if a package
> marked as 3.7 it does not guarantee that it will work, because chances
> are high that there are conflicts with other packages marked as 3.7.
> Therefore I pretty much ignore this category completely.
> Thinking about it, I'd find it interesting to try out the opposite
> approach: to list only information of the following kind: Package A
> Version 1 is known to have a conflict with Package B Version 3. I can
> imagine that this would be much less information and thus much easier
> maintain. It would be necessary that this information can be supplied
> anyone, not only the package developers.
>> So given the two "safety mechanisms" we have now - the check for
>> published, and the check for correct Squeak version - the
>> install-methods that do not specify a specific release are much more
>> "ok" to use.
> With all respect, I disagree. To load the latest version of a package
> regardless of the Squeak version I use seems a very common use case to
> me. I would even dare to bet that most people will answer yes to both
> questions in almost all cases.
You have some points, but I still think that Goran's current scheme for
installing a non-release-specific package is best for now.
If a package release is listed as not being compatible with 3.7, that
tells me one of two things. Either:
1. The package doesn't work with 3.7.
2. The package is not very well maintained.
When a new alpha release comes out, such as 3.8alpha which just
arrived, sure, it will take a little while for various package owners
to add a 3.8-compatibility to their packages. But 3.7 has been in
development for several months now (and in beta/gamma for a few
months), so if a package maintainer can't be bothered to check whether
their package works with the current Squeak release for over 6 months,
you know the package isn't well maintained.
Also, I think the warnings will help package maintainers to keep their
Squeak-versions categories up-to-date if their package is used by a lot
of people. :)
I agree that you can still have problems with packages conflicting with
each other... the current scheme is a bit simplistic and doesn't handle
that. But there's a better dependencies/configurations scheme which is
planned by Goran (for 3.8, I believe :) ).
More information about the Squeak-dev