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

goran.krampe at bluefish.se goran.krampe at bluefish.se
Wed Nov 19 13:38:00 UTC 2003


Markus Gaelli <gaelli at emergent.de> wrote:
[SNIP of stuff not needing comment]
> >> Say if Torsten Bergmann is creating a Developer-Package, he just says 
> >> on
> >> which versions of RB, LookEnhancements... this would work. And 
> >> versions
> >> this
> >> "Developer-Package". No need for configmaps.
> >
> > And what if I discover it works with other releases too? Can I then 
> > make
> > yet another release of Torstens package? And is that a fork?
> See below.
> > And what
> > happens to all other package releases that depends on Torstens release,
> > they suddenly points to an old release -
> - and are sure to work as they did before -

Yes, but not with *my* configuration! Because *my* configuration
suddenly became *another release*. Even though it is the exact same
code.

I think this is a clear cut example of when two concepts are mixed. When
a dependency points to a package release it means that "Hey, I work fine
if THIS CODE is around.". And now you are making releases with the same
code that would have worked too, but since you are making new releases
that knowledge is lost in the soup.

To explain:

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. ;-)

> >  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.

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.



More information about the Squeak-dev mailing list