On Sat, Dec 12, 2009 at 6:56 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> 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.

But that is not true, in fact the repositories are prepared on package
upload so that
every download is first an update and then an install/upgrade.
The update just synchronizes the client db (a file with the latest
package list and
package dependencies and "provides" hints for the dependencies solver)
with the updated
server list.
Then goes ahead and do a dependency solving algorithm. Doesn't download any
package to do this, it uses the meta information got from the spec file uploaded
and concentrated in this db and does its job.
The same can be made in squeak with metacello. On upload time, the
server software
in charge of the repository can analyze the configuration of the
package and generate
a new db list with the apropriate meta information.
When a cliente image updates its own lists get this new db and then proceed to
solve the dependency graph. When a solution is found, then downloads the
appropriate package versions for the package installed and all its dependencies.

Complex, maybe, for the developer of the client and server software.
But for the user is just a simple do it in a workspace. For example, from a core
image, just open a workspace and put (pseudo code):

Metacello update;
 install: 'Seaside'.

And this will grow the core image to a full image with lots of
packages installed
automatically.


>
>>> 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.

The same applies to formats that grow over time without a version number
indicating what version is this format. Just open a new excel file in
a very old excel
install. Nobody spect it to work. The same for trying to run a
Makefile from 2010 in
a unix from 1980.
 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.

Granted, but also, but it is the same that happens right now with squeak map and
squeak source abandoned packages. They no longer work in squeak or
pharo. They need
modification to run in newer images. That is something that we accept.
I don't believe in
the idea of coding ones and forever. That is imposible. Even the trunk
right now is better
that the squeak version it started from. That surely will render
several packages broken.
But it is good, because the image is more healthy. And the price for
the health is to
invest some time in adapting old code to the new environment.


>
>>  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.

Well, then we'll wait for the next marvelous thing that
squeak/smalltalk is going
to provide to show the world how dumb they are for using something that works
now instead of waiting for the lightweight, fast, non-bloated, well
engineered tool you'll
have tomorrow, or the next month, or ...


>
> Cheers,
>  - Andreas
>
>

Miguel Cobá
http://miguel.leugim.com.mx