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
|