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@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:
- Keeping track of which package releases are in which Squeak
versions, with a UI that requires no extra activities by the users.
- The ability for users to set up their own package universes without
needing to coordinate withany central authority.
- The ability to create nested universes and to have packages in inner
universes automatically propagate to universes which contain them.
- 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