El lun, 22-02-2010 a las 04:05 -0800, Andreas Raab escribió:
> Torsten Bergmann wrote:
> > Andreas Raab wrote:
> >> BTW, for people who'd like to install HelpSystem with Installer instead 
> >> of Metacello, use this:
> > 
> > NOOOO!!!!! 
> 
> Heh :-) I think I'm starting to understand our differences (actually 
> more from your private mail than from this one) and I think it comes to 
> what Metacello is *today* vs. what Metacello *may be* in the future.
> 

Well, a thousand steps journey starts with the first step. Or you want
some finalized, full featured software appear from the nothing, without
users feedback that help their subsequent developement?

> First of all, I completely understand what a package management system 
> is, what it does, why it's a good idea. You'll hear no arguments about 
> that other than my opinion that we do indeed need a package management 
> system. Urgently.
> 
> My problem with Metacello today comes from that I've been looking at 
> Metacello with the eyes of what I'd expect to see in a package 
> *management* system, namely:
> 
> a) The ability to declare packages and dependencies
> b) The ability to install packages
> c) The ability to reflect about package
> d) The ability to uninstall packages

Where is defined a package management this way?
Wikipedia isn't as restrictive in their funcionality. It says: "a
collection of tools to automate the process of installing, upgrading,
configuring, and removing software packages from a computer."

Installing, upgrading, configuring and removing.

By my count Metacello does three of that four thing already:

Install
Upgrade
Configure (By means of Monticello pre/post scripts and Metacello
pre/post doits)
Unload (this is planned but not a requirement for 1.0. The overrides
installed by new methods are a know problem but nothing that can't be
resolved.)

> 
> If you look at the above criteria, then Metacello *today* only really 
> supports one of these four criteria:
> 
> a) The declarative nature of packages and dependencies is violated 
> because Metacello requires to store and run code to create a package 
> spec. In other words, the package spec is transient, the real input to 
> Metacello is *code* (a ConfigurationOfXXX) which makes it all but 
> declarative. What's worse, that ConfigurationOfXXX code has specific 
> dependencies on other code (Metacello) which it first loads and that 
> again has other dependencies (Gofer for example). All of this completely 
> violates the idea of why one uses declarative specs, namely to have 
> *fewer* dependencies that one needs to deal with in order to 
> "understand" the spec.

I don't care about that, and they are only 2 dependencies and of course
they also depend on Strings, OrderedCollection, Arrays, and whatever.
You have to draw a line in the packages installed and you can include
Gofer/Metacello in the core, just as a stdc or rpm or deb or emerge is a
part of a linux distro. BTW, the aptitude dependencies are:

miguel at laptop:~$ aptitude show aptitude
Package: aptitude
Status: instalado

Version: 0.4.11.11-1+b2
Priority importante
Section: admin
Developer: Daniel Burrows <dburrows at debian.org>
Uncompressed size: 10.0M
Depends: libapt-pkg-libc6.9-6-4.8, libc6 (>= 2.3.4), libcwidget3,
libept0 (>=
            0.5.27), libgcc1 (>= 1:4.1.1), libncursesw5 (>= 5.6
+20071006-3),
            libsigc++-2.0-0c2a (>= 2.0.2), libstdc++6 (>= 4.2.1),
libxapian15,
            zlib1g (>= 1:1.1.4)
Recomends: aptitude-doc-en | aptitude-doc, libparse-debianchangelog-perl
Suggest: tasksel, debtags

More that two dependencies and nobody is complaining about the size.
Even ncurses, that has nothing to do with a package management system,
but if you want to use the graphical interface there you have it. 
Of course the image is smaller and the size of Metacello is more
visible. 

> 
> b) Installation works.
> 
> c) As far as I understand, Metacello doesn't know what it has loaded. I 
> don't think there is a way to ask Metacello "please show me everything I 
> have loaded" or "uhm, which version of HelpSystem did I load? was that 
> version 1.0 or 1.1 or what?".

ConfigurationOfGlamoroust
Loader will have
And that isn't something that you can't discard a package for. As I said
initially, is a work in progress. Not everybody can produce a finished
product.

> 
> If I'm not mistaken there is also no notion of a "provided" package that 
> doesn't directly correspond to MC package granularity, for example 
> knowing that loading FFI-ar.10.mcz provides the same code that's in 
> FFI-Pools-ar.1.mcz, FFI-Kernel-2.mcz, and so on. (there are many 
> variants on this topic for example the difference between the Shout 
> release and ShoutCore we have in trunk etc)

Work in progress again. This is part of the metadata but for now hasn't
been implemented. 

> 
> d) Well, there's just no support for unloading, which is a feature that 
> I'd expect from a real package management system. Together with the 
> previous point that makes it real hard to do any actual *management* of 
> packages.

Oh yes, current Squeak shines here right. Where the management of
package is the script in some class side method to unload everything tha
is unloadable. Good.
Again, this is work in progress.

> 
> So of the four corner stones of a package *management* system, the only 
> thing that's really working today in Metacello is the part that installs 
> packages. Which is exactly why Metacello today looks a lot like a 
> glorified version of Installer :-)

Yes, because Installer can manage dependencies right?

> 
> In any case, you've made it quite clear (in your other email) that you 
> expect these issues to be addressed in the future. I'm looking forward 
> to reevaluating Metacello at this point again.

Oh thanks, or maybe you'll surprise us with a new "well done" package
management system a la Traits that show us all mean developers around
the world how things are to be made.

Please, please, stop this nonsense. Dale is doing a great work and he is
wise enough to not get in irrelevant, uninformed discussion, but don't
bash their work just because don't have all the features *you* want. As
you can see, there are a lot of people using it everyday and not caring
about the *big* problems you find with the tool for their operations.

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