Yet Another Dependency Proposal: Packages and PackageVersions, that is it

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Nov 19 16:03:51 UTC 2003


Hi!

Markus Gaelli <gaelli at emergent.de> wrote:
> Hi again,
> 
> > You release Apple as:
> > Apple 1.0 depends on Banana 1.0 and Orange 1.0
> >
> > I release FruitBasket as:
> > FruitBasket 1.0 depends on Apple 1.0
> >
> > Then you discover that, hey - it Apple 1.0 also works with Orange 1.1 
> > so
> > you release:
> > Apple 1.1 depends on Banana 1.0 and Orange 1.1
> >
> > (note: If you go this route you will also start looking for using
> > booleans so you would really have liked to say:
> >     Apple 1.1 depends on Banana 1.0 and (Orange 1.0 or Orange 1.1)
> > ...which is what Debian's package system does. Personally I do not want
> > to go there, it just gets so messy and complicated)
> >
> > Now, my package release FruitBasket 1.0 still refers to Apple 1.0 so
> > your new discovery that Orange 1.1 is OK is just lost to FruitBasket!
> > And then someone tells me, and oops - cascade - I must also make a new
> > release just because you did one. Sigh. ;-)
> I think that it would be dangerous for you to assume that this would 
> work
> out of the box. Maybe fruitbasket starts to rot if it included Orange 
> 1.1, no?

No - FruitBasket depends on Apple - not Orange. We can't have *every*
package release specifying *every* dependency deep first all the way
down to the metal.

> But see below, this would work perfectly fine with my proposition as 
> well.
> >>>  thus you get "cascading
> >>> changes" which will simply create a big soup of releases that are 
> >>> only
> >>> meant to "adjust" the dependency information.
> >> I thought we agreed on the fact, that both our solutions are facing
> >> that problem,
> >
> > Eh, where did we agree on that? I don't! :-) :-) In my model package
> > configurations only have a *current* version. I don't keep track of the
> > old ones. So if a new configuration is discovered - sure, I add it. But
> > it doesn't produce new releases of the packages as a side effect.
> You keep on creating configurations while I create versions. That is it.
> Nothing more nothing less...

Big difference IMHO, but obviously all my arguments and motivations are
landing flat on the ground here - I have exhausted them and nothing
seems to stick.

So fine, I will implement mine and it will be done on top of SMResource.
And we will see.

> In my model the whole fruitbasket also can be loaded together
> with the most hip versions of its prerequisites, if you want.
> It is just not acknowledged at that time, that this works.
> If somebody trusted acknowledges, fine, make it a baseline-version.
> (1 click technique)
>   I really don't see any difference here to your model which makes it a 
> configuration.
> > regards, Göran
> >
> > PS. I hear you are thinking in terms of team development/Envy. Please
> > remember that packages/SM is not the same thing. It obeys different
> > social mechanics, different expectations, timespans etc. Envy might 
> > cope
> > fine with explosions of versions etc - but that is not what I want in
> > SM.
> Which exactly? Why are they not covered by my model?

What I meant is that I don't want to create releases "willy-nilly" in SM
like you can can do almost by routine in Envy. SM is *not* a CM tool, it
is not Monticello.

> Actually I would be very interested in your thoughts about my ideas to 
> integrate
> the SqueakPeople trust model in SM* here.

That is surely something we should/will do eventually. But I don't think
personally that I want to have co-maintainers accessing the packages I
mantain simply based on a level of trust on SqP.

I want to assign that trust manually. And you can already do that in
SM2.

> Regards,
> 
> Markus

regards, Göran



More information about the Squeak-dev mailing list