Hi Lex,

There are two seperate issues here.

1. one map vs. multiple maps
2. versioned vs. unversioned "dependencies/configurations"

---------------

Regarding the first:

- I agree with you on the many of the benefits of having multiple maps 
and certainly don't see why we shouldn't be able to have them.  And
- I disagree, however, that having multiple maps makes it particularly 
easier to support packages for multiple squeak versions
- I also think it's important to realize that there are trade-offs.  You 
list all the things you get without any coding by having multiple maps. 
  But there things you can no longer get without coding, like having one 
package release that does work in multiple images and needs to be 
released into all the maps at once, having maintainer data kept up to 
date in all the maps, easily trying the version that you know works in 
3.7 in 3.6 to see if it works there.

Summary: if we want multiple maps so people can run their own ones, etc. 
then fine--there's no reason we shoudl hardcode the URLs or avoid a UI 
to let you have more than one map.  But I see no compelling reason to 
use a unique map for each squeak version.

--------------------

Regarding the second:

- I never said Goran *never* called them dependencies.  All I meant is 
that when he was explaining them to me he called them configurations. 
Why are we still arguing about this?  We seem to all agree that storing 
the versions that work is a good idea and that forcing the user to only 
be able to load that version is a bad idea.
- I use Debian myself and I agree that it works great, *most of the 
time*. I doesn't *always* "just work", however.
- Usually when it doesn't work (in my experience) it is because a 
package hasn't been updated yet to work with changes made in a new 
version of one of its dependencies.  The newest versions of packages do 
not always work together.

Finally, I still don't understand why you think that you can't upgrade 
A,B, or C.  As I worked through the scenario I could upgrade anything I 
wanted.  The only time you can't upgrade something is if two different 
packages depend on features that are incompatible between two different 
versions.  And that's just a fact. In all other cases, the knowledge of:

  a) which versions work together,
  b) which versions don't work together, and
  c) the level of compatibility from one version of a package to the next

will help the system build or guide the user through building a working 
collection of packages.

It seems far more accurate to me to record:
   - A1 requires B
   - A1 works with B2
   - A1 does not work with B1
   - B3 includes on minor, compatible changes from B2
than to record (as debian does, I think):
   - A1 requires B >= 2
or (as you suggest):
   - A requires B

We can implement the behaviour of either of the other two lists from the 
first.  The first contains more information.  The information is all 
easily obtained.  The first list is the way users who are testing or 
using the packages think about it anyway.

I feel like I've exhausted my arguments here so I may wind down my 
participation in the thread at this point... :)

Cheers,

Julian


lex at cc.gatech.edu wrote:
> Guys, I never disagreed that it is possible to get along with a single
> map.  However, multiple maps seem to simplify some things and to enable
> some other things, all with no additional code beyond supporting
> multiple maps.  With multiple maps, you immediately gain the following
> abilities:
> 
> 	1. Keeping track of which package releases are in which Squeak
> versions, with a UI that requires no extra activities by the users.
> 	
> 	2. The ability for users to set up their own package universes without
> needing to coordinate withany central authority.
> 	
> 	3. The ability to create nested universes and to have packages in inner
> universes automatically propagate to universes which contain them.
> 	
> 	4. The ability for a package to be maintained by different people in
> different package universes, e.g. if I only support Chuck in 3.7, Joe
> can volunteer to support it in 3.0.
> 
> I find this list striking, when one considers that all of these features
> happen automatically and with no coding at all.
> 
> 
> Now, perhaps I am misunderstanding the purpose of SqueakMap.   If
> SqueakMap wants to be a catalog of everything, then I have misunderstood
> and that is fine.   In that case, however, I do suggest that we start
> work on a new tool which is a "package universe browser".  Users should
> have some tool that lets them select packages from a menu, install them,
> and have it just work.  They should be able to do this even if they
> aren't following the main development version, and they should be able
> to integrate their own packages into the system without needing
> cooperation from a central authority.  If SqueakMap is not intended for
> these purposes, then we should put together something else.
> 
> 
> Regarding versioned dependencies, Julian, Goran did indeed call the
> configurations "dependencies".  And please consider that in the A,B,C
> example there was *never* a time that I could upgrade *any* package.  If
> this is typical, then the configurations will always be ignored by the
> user, which makes them pointless.  If we want a dependency system that
> the user will practically never want to override--and I think we can get
> there--then it seems that we should not put fixed version numbers in the
> dependencies.
> 
> 
> Overall, I have followed communites where the packaging system causes
> its users headaches (RedHat, Windows DLL's), and I have seen one
> community where the packaging system Just Works (Debian).  I have
> thought about this issue a good bit, and I am simply pointing out some
> conclusions that I expect will make our system work better.  Squeak is a
> decentralized playground, though, and everyone is free to play in it
> however they like.
> 
> 
> -Lex
>