On 5/18/2010 11:35 PM, Göran Krampe wrote:
> On 05/19/2010 07:44 AM, Andreas Raab wrote:
>> Feedback welcome! Patches even more :-)
>
> I haven't even looked yet - BUT... I got reminded by a nice "feature" in
> Lunar Linux's package management tools when you were discussing "default
> groups" etc. Perhaps I misunderstood - but I guess its about "questions
> to the user when installing stuff".

It's a little off. What I was referring to is that in Metacello you can 
define 'groups' of packages. I think the intent is that such groups are 
like installation options, e.g., something like

Installing Foo:
   [x] Foo-Core (required group)
   [ ] Foo-Tests (optional group - unit tests)
   [ ] Foo-Help (optional group - documentation)

The current Metacello definition is such that if it exists, the 
'default' group is being installed. But that can only be a single group 
so in the case that I wanted to structure the above into three separate 
groups but by default have both Core and Tests selected I would have to 
create a separate default group for that. And that creates confusion 
because you can't really present that in a UI properly.

What I'd like to see instead is something where we can define a little 
more of the status of these groups. For example: #required (for groups 
that must be installed), #default (for groups that are optional, but 
installed by default), and #optional (groups that are optional and not 
installed by default). The assumption being that the groups are largely 
non-overlapping sets of packages that I can independently select. But I 
have no idea how Dale intended this to be used so I'll have to wait 
until he can comment on this.

> Earlier Installer introduced (Keith IIRC) some mechanism to provide
> automatic answers to regular popup dialogs etc. A hack, but still.

I think this may actually exist in Metacello. I've seen a 
'supplyingAnswers:' part of the spec that smelled a lot like that very 
hack ;-)

> When you perform an installation of a module the dependency system
> figures out the total list of packages to install - and then compiles a
> *complete* list of questions for all modules that it *will* install and
> then asks the user for their answers. Thus, when the install actually
> begins after the questions have been answered it is fully automatic and
> is nicely done "in the background".

Ah, interesting! Yeah, that's a pretty good idea. So basically the 
packages announce beforehand what info they need and later on just use 
these answers?

Cheers,
   - Andreas