Anybody want to help us Guides fix a process bug? (was: Re:[Fwd: Package Loader version filtering ...

cg at cdegroot.com cg at cdegroot.com
Wed Feb 12 18:14:00 UTC 2003


Daniel Vainsencher <squeak-dev at lists.squeakfoundation.org> said:
>So what we need is this - a patch to SMLoader such that it accepts all
>packages for it's own version, and, if it's own version ends with
>'alpha', also all package for the previous version. Where previous
>version should correctly handle nonobvious cases like 4.0. One approach
>is to store a list of "X's previous version was - Y". Another angle
>might be a patch to Squeak that remembers what it's previous version
>was, though I'm not sure that should be in the base image.
>
What you want, I think, is a 'requires'/'provides' pair. A Squeak base
release 'provides' some interface version, a package 'requires' some
interface version. I'd decouple this from the published version number,
because with all the mods we're going to have on the 'outside' with
little change on the 'inside' (just like now - two Squeak versions are
internally the same) they are going to deviate quickly. 

Probably you want to match on as much detail as 'requires' provides. So
with current 3.5 Squeak providing '3.0', a package could require '3',
'3.0', or even '3.0.1' (if there ever would be a 3.0.1 patch release).
If you call this package 'base' or 'core', you'd have 
- Squeak 3.5alpha provides 'base-3.0'
- Package foo (most packages, I think), require 'base-3'.

ObDebianAnalogy: most packages require a certain libc version.




-- 
Cees de Groot               http://www.cdegroot.com     <cg at cdegroot.com>
GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
Cogito ergo evigilo



More information about the Squeak-dev mailing list