Markus Gaelli <gaelli at emergent.de> wrote:
> Hi Goran,
> 
> > I simply don't want it encoded inside the package release because it
> > would still force me to do a new release if I need to change that
> > information. I think this is just a "tool/UI issue". Associating a
> > default config to the release will be catered for in the UIs.
> Ok, I just want to have some kind of entity which
> "serves as the complete egg" and which is easy associated
> with the package I am interested in.
> 
> And the easiest association I can think of is "sameness".
> 
> If the UI fools me to have this, it is ok for me.
> If I want to install SmaCC Development, I usually don't
> want to know that this requires the RB.
>
> So some developers might be interested in the "naked"
> SmaCC Development, but I strongly believe that the end
> user thinks and should be able to think in terms of the
> whole enchilada, when he thinks "package".

Of course. The configs aren't even meant to be "selected" and most of
the time not even interesting to look at. The idea is that they simply
are in the map and given a selection of a package (or typically several)
SM (or specifically the engine, which doesn't need to be part of SM) can
calculate all needed prereqs using these configs.

> > Putting it inside the package only works for the package formats that
> > "support" that. SM handles packages in a variety of formats. I don't
> > want to invent different ways of embedding this into these formats.
> 
> I thought we wanted to establish a new, maybe better standard now?
> There are also Projects on SM, and they will be certainly difficult to
> enhance.

Well, AFAICT we don't really need a new standard for code packages.
Really. We already have Changesets, .st-fileouts and Monticello. There
is no need for yet another format.

And we could even be fine without Monticello *in this respect*. <- note
emphasis

Because the dependencies etc are not IN the packages. They are instead
in the map encoded in package configs and also a few attributes on
package releases (not the file, the instance of SMPackageRelease in the
map).

I mean - for installing a piece of code into an empty image - changesets
or good ol fileouts work exactly as good as the Monticello format.

So if there is dependency information available to a resolution engine
then those formats are just fine. Unless we start talking
uninstallation, co-development, etc etc of course.

So sure, we are gradually moving towards Monticello for many, many
reasons. But for *this* issue - dependencies between packages and
resolving them in order to build images - it isn't really needed. Using
my scheme you will even be able to have a ChangeSet being dependent on
having a Monticello package and a .st package already installed. Or
whatever formats there are.

Note for example that I just (upon Diego's request) added .tra format.
For translation files. So you will be perfectly fine depending on a
translation! and I also envision us having kernel images that you can
depend on! And hey, perhaps even VMs and precompiled plugins!

I know this may sound like  "flame bait" - but read carefully. :)

> Regards,
> 
> Markus

regards, Göran