2009/12/12 Miguel Cobá <miguel.coba at gmail.com>:
> On Sat, Dec 12, 2009 at 1:43 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
>> Miguel Cobá wrote:
>>>
>>> Maybe more attention to the real uses of the technology
>>> outside the "core" squeak is needed here.
>>> Since some months ago, Dale Henrichs has made available Metacello
>>> that doesn't tries to "fix" monticello, but to build on top of the
>>> limitations of it by treating monticello as what does better:
>>> to load a single version of a given package in the image.
>>> Then it adds the apropriate "package" dependencies in
>>> a higher level. No need to feature creep monticello but use
>>> it as a sound base for solving the issues you mentioned.
>>
>> I do not understand which problem domain Metacello is addressing and how. If
>> you have more information, this would be very welcome.
>
> http://www.google.com.mx/search?hl=en&source=hp&q=metacello&btnG=Google+Search&aq=f&oq=
>
> http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-for-monticello/
>
> Quoting from the blog post:
>
> "
> Metacello: Package Management for Monticello
>
> August 25, 2009 in Deployment, Metacello, porting
>
> Rate This
>
> Quantcast
>
> [1]
>
> Metacello is a package management system for Monticello. A package
> management system is…
>
> …a collection of tools to automate the process of installing,
> upgrading, configuring, and removing software packages from a
> computer. Distributions of Linux and other Unix-like systems typically
> consist of hundreds or even thousands of distinct software packages;
> in the former case a package management system is nice, in the latter
> case it is essential.
>
> Packages are distributions of software and metadata such as the
> software’s full name, description of its purpose, version number,
> vendor, checksum, and a list of dependencies necessary for the
> software to run properly. Upon installation, metadata is stored in a
> local package database.
>
> A package management system provides a consistent method of installing software…
>
> Last April I finally became fed up with the lack of a decent package
> management system for Monticello and decided to write my own from
> scratch. I wanted a package management system for Monticello that was
> consistent with the important features of Monticello:
>
>    * Declarative modeling. A Metacello project has named versions
> consisting of lists of explicit Monticello package versions.
> Dependencies are explicitly expressed in terms of named versions of
> required projects. A required project is a reference to another
> Metacello project.
>    * Distributed repositories. Metacello project metadata is
> represented as instance methods in a class therefore the Metacello
> project metadata is stored in a Monticello package. As a result, it is
> easy for distributed groups of developers to collaborate on ad hoc
> projects.
>    * Optimistic development. With Monticello-based packages,
> concurrent updates to the project metadata can be easily managed.
> Parallel versions of the metadata can be merged just like parallel
> versions of the code base itself.
>
> Additionally, the following three points are important considerations
> for Metacello:
>
>    * Cross platform operation. Metacello must run on all platforms
> that support Monticello: currently Squeak, Pharo and GLASS.
>    * Conditional Monticello package loading. For projects that are
> expected to run on multiple platforms, it is essential that
> platform-specific Monticello packages can be conditionally loaded. At
> the moment, conditional loading is specified based upon the following
> attributes:
>          o #common. Code that is common across all platforms.
>          o #squeakCommon. Code that is common to Squeak and Pharo.
>          o #squeak. Code that is specific to Squeak.
>          o #pharo. Code that is specific to Pharo.
>          o #gemstone. Code that is specific to GemStone.
>
>      It should be possible to inject project-specific attributes, so
> code that is dependent upon attributes not covered by the standard
> list can be conditionally loaded. For example, in GLASS, different
> Monticello package versions are loaded based on which version of
> GemStone/S is running (i.e., version 2.0 versus 3.0).
>    * Compatible with MC2. It must be possible to manage Metacello
> projects that are based on alternate Distributed Source Code
> Management systems like Monticello2.
>    * MIT license."
>

I am clueless, why people eagerly jumping into the boat in one case,
but prefer to stay away from it in another.
Something irrational in this..

The Sake and Bob [1] projects were announced more than a half year
earlier than Metacello, but there are few people who ever took time to
evaluate it (including me).
But sure, why we would need to ever look at it, if we got a new shiny toy?

I have nothing against Metacello project , neither beloved with
Sake/Bob solution(s). I know very little about them.
But if i would need a packaging tool, i'd first consider alternatives
& look for existing tools and evaluate them before jumping with closed
eyes.

[1] http://wiki.squeak.org/squeak/5953

-- 
Best regards,
Igor Stasenko AKA sig.