goran.krampe at bluefish.se wrote:
>  The "separate package pool per Squeak version" idea - I really don't
> understand it. We can categorize the packages on SM whichever way we
> want. We already have categories for Squeak version. We can add
> smartness to SMSqueakMap/loader to warn the user etc. What is it we are
> not catching? And what would be solved?

One issue that the SM categories do not cover is that "Celeste for 3.6"
and "Celeste for 3.7" should not have to be the same package.  In fact,
Celeste for 3.6 should most likely be frozen and only updated when a bug
is found.  Celeste for 3.7 on the other hand is actively developed.  It
would be nice if my tools all just say "Celeste" and that they figure
out automatically that I mean "Celeste for 3.7".

The current practice of literally renaming packages to things like "RB
for 3.6" seems like something that ought to be done for *every* package.
 And thus, it seems like it should be automated.  I thought having
separate SqueakMap's might be a good way to automate it before you clued
me in to the issue of the password maps.  But anyway, at some point we
probably do want to have a separate package map for each version of
Squeak.


Andreas wrote:
> But if you start to think about an evolutionary model where you'd really
> take updates from lots of different places it throws various of the basic
> assumptions that we use today right out of the window

Note that the fullest extension of this idea doesn't work: you cannot
reasonably have multiple packages pools around and then have people
grabbing from whichever pools they like, and expect the packages to
function correctly.  Just look at the RedHat world to see what happens
when people think that a package format -- RPM in this case -- is enough
to keep a system consistent.  I cringe whenever I see a page saying
"here's the package in RPM format" -- the format itself is unimportant!

Still, it is quite possible to have multiple pools even in a model where
"packages belong to a single pool".  You can simple have a super-pool
holding a bunch of mutually compatible individual pools.  The name of
one super-pool might be "pools for Squeak 3.7", and individual pools
might be "Main Packages for 3.7", "Lex's stuff for 3.7",  and "Andreas's
stuff for 3.7".  Let me note, as you are all tired of hearing, that
Debian has been served well by this idea of packages within pools within
superpools.  Debian does not have a "DEB hell" to correspond to "RPM
hell" or "DLL hell".  We don't need to copy them, of course, but it
bears considering how it is that Debian has managed to avoid a very
common problem in packaging systems.



Avi Bryant <avi at beta4.com> wrote:
> This is something MC doesn't address right now, and it's something that 
> cannot be addressed automatically, but it's certainly something that 
> could be addressed manually within the context of MC.  I fully intend 
> to make MC "sufficient" as a system for managing all source code in 
> Squeak, including the base image itself.  We're not there yet, and it 
> may not get adopted for that purpose, but it will be possible if we 
> decide to use it.

As you agree, the issue fundamentally needs manual effort.  Monticello
will not be sufficient to just make this problem go away by itself, but
that's okay because *no* code management system can make it go away and
still remain tolerable.

To get an idea of how severe this issue is, notice that every statically
typed language disallows major changes to existing objects.  Let that
sink in.  Type checking, a dirt simple analysis that is a long, long way
shy of guaranteeing correct behavior, still cannot handle objects that
have their layouts and sets of methods rearranged arbitrarily.

To give a concrete example, suppose in version 3 I have a Person class
with a "name" field, and in version 4 I have a Person class with
separate "firstName" and "lastName" fields.  Now suppose an image with
version 3 tries to upgrade to version 4....

Tools cannot make this kind of problem go away.  The author needs to at
least tell the system how to update the classes.  That said, tools can
help, but my point is that it's a non-answer to say tool XYZ is on the
way that will solve the problem.



Avi Bryant <avi at beta4.com> wrote:
> It's possible for a monolithic image.  I'm not convinced it works for 
> multiple packages. 

I don't see how, for this particular problem, it is relevant whether the
image is monolithic.  That just means the update comes in through the
update stream instead of via a new CS, MCZ, or other file being loaded.


-Lex