[squeak-dev] Re: Packages, Packages, Packages

Andreas Raab andreas.raab at gmx.de
Sun Dec 13 00:56:52 UTC 2009


Miguel Cobá wrote:
>> The biggest issue with Metacello I'm seeing so far is that it muddles the
>> installation script with dependency management and metadata.
> 
> But that is the same with the .spec file from a RPM package. They have both
> the metadata about the package (packager, date, release number, version, etc),
> the install scripts (pre/post install/uninstall scripts for things to
> configure in the host system). I can't see the problem here.

You can parse the RPM spec and do a good bit of analysis without running 
the install or any other scripts. Yes, at some point there are scripts 
involved in the installation, but I don't need to execute a shell script 
*before* I can find out that this package (for example) has a build 
requirement of kdebase3-devel. Tell me how I find out anything about a 
Metacello package without running it.

>> Very
>> troublesome because it means you can't even *look* at a Metacello
>> configuration from Squeak 3.8 or ealier.
> 
> Why would you want to do that. 3.8 is dead, must be dead and should be kill.

The point is not about 3.8. The point is that because Metacello insists 
on using Smalltalk code, the package definitions are inherently tied to 
very specific language and environment versions. If you use a language 
construct in your package that's new, no older version will be able to 
read it. If your package uses a method that was removed it won't load 
into a newer version. One of the main points about package management 
systems is that they are supposed to be robust - Metacello seems very 
brittle because it inherently depends on the environment that the 
description was created in. Five years from now, you will not be able to 
analyze the package configurations you created today. Because 
*something* will have changed and break that code and as a consequence 
the entire package.

>  Extremely disturbing considering
>> that in order to do dependency analysis one must run untrusted code to
>> obtain the dependencies (so forget about server-side dependency analysis).
>> And unfortunate because it means that Metacello has hardwired assumptions
>> about its interactions with the rest of the environment (Gofer, OB etc)
> 
> Yes, but that is the compromise. You choose your tools and build some new tool.
> Maybe Installer isn't the right tool for building Metacello. Maybe
> because Gofer didn't exist Metacello didn't existe before.
> Remember, new knowledge leads to even more new knowledge. Tools are multipliers
> of the ideas and producers of new ideas not imagined before.

Perhaps so, but Metacello feels bloated. It just doesn't feel right to 
use that much code for something that simple.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list